Design methodology question

[msch-prv]

I am about to embark on creating a mid-size web project that heavily
relies on db interactions.

Since most pages will contain recurring form elements (input text
boxes, dropdown boxes, radio buttons, submit forms, tables, etc.), I am
thinking of using blocks to insert components to each page. All
standard elements would be instances of form element classes. Calling
up these objects would generate customized html code.

Ex: a cbo box could be instantiated in a script via:
<p>Select Customer:</p><?php creatElement($cboName, $cboCSS, $cboVal,
$cboOpt, ..); ?>

Would such an approach be more efficient that the traditional
line-by-line approach wrt. debugging, maintenance, etc. ? (I really
dread mixing php and html.). While I like Smarty's templating approach,
it seems Smarty still requires linear coding to do code translation.

I visualize html pages in terms of grids where cells could be filled up
by html block components. Is this approach somewhat too fancy?

Thanks for any insights,

Mark

[David Haynes]

ms******@bluewin.ch wrote:

I am about to embark on creating a mid-size web project that heavily
relies on db interactions.

Since most pages will contain recurring form elements (input text
boxes, dropdown boxes, radio buttons, submit forms, tables, etc.), I am
thinking of using blocks to insert components to each page. All
standard elements would be instances of form element classes. Calling
up these objects would generate customized html code.

Ex: a cbo box could be instantiated in a script via:
<p>Select Customer:</p><?php creatElement($cboName, $cboCSS, $cboVal,
$cboOpt, ..); ?>

Would such an approach be more efficient that the traditional
line-by-line approach wrt. debugging, maintenance, etc. ? (I really
dread mixing php and html.). While I like Smarty's templating approach,
it seems Smarty still requires linear coding to do code translation.

I visualize html pages in terms of grids where cells could be filled up
by html block components. Is this approach somewhat too fancy?

Thanks for any insights,

Mark

This approach is very similar to the Java tag libraries approach. You
may want to check out their design to piggy-back on their experience. I
would suggest that you especially look at the html taglib set.

The lack of polymorphism will be a bit of a hindrance but this can be
worked around by using arrays instead of individual function variables.
For example:
<p>Select Customer:&nbsp;<?php htmlSelect($attributes, $options);?>

Where $attributes is an associative array of tag=value for the
attributes of <select> and $options is an associative array for the
<option> attributes.

-david-

[Chung Leong]

ms******@bluewin.ch wrote:

Would such an approach be more efficient that the traditional
line-by-line approach wrt. debugging, maintenance, etc. ? (I really
dread mixing php and html.). While I like Smarty's templating approach,
it seems Smarty still requires linear coding to do code translation.

That approach sounds good in theory but I've found it doesn't work very
well in practice. User interface tend to require a lot of little
tweaks, sometimes to work around browser difference (layout quirks,
etc.), sometimes just be make things look aesthetic pleasant.
"Shimming" a page, as some might call it. At times it's hard enough to
get one page to look right, let alone trying to make the same piece of
HTML work in multiple locations. A lot depends on how tight a design is
visually. When it's unforgiving, you want to give yourself more
flexibility.

[David Haynes]

Chung Leong wrote:

ms******@bluewin.ch wrote:

Would such an approach be more efficient that the traditional
line-by-line approach wrt. debugging, maintenance, etc. ? (I really
dread mixing php and html.). While I like Smarty's templating approach,
it seems Smarty still requires linear coding to do code translation.

That approach sounds good in theory but I've found it doesn't work very
well in practice. User interface tend to require a lot of little
tweaks, sometimes to work around browser difference (layout quirks,
etc.), sometimes just be make things look aesthetic pleasant.
"Shimming" a page, as some might call it. At times it's hard enough to
get one page to look right, let alone trying to make the same piece of
HTML work in multiple locations. A lot depends on how tight a design is
visually. When it's unforgiving, you want to give yourself more
flexibility.

Chung:
I was thinking about this at a finer-grained level than you seem to be
in that I was thinking that msch-prv was thinking of automating the
common HTML elements rather than doing something more complex.

While I agree that some sites required a lot of "shimming", those are
also the sites that fall over with every browser upgrade and/or page resize.

Do you think that, say, wrapping <select>, <img> or the various <input>
tags in functions is really going to lead to big layout issues? It seems
to work well enough in the JSP/JSF space...

-david-

[Tony Marston]

<ms******@bluewin.ch> wrote in message
news:11**********************@c74g2000cwc.googlegr oups.com...

I am about to embark on creating a mid-size web project that heavily
relies on db interactions.

Since most pages will contain recurring form elements (input text
boxes, dropdown boxes, radio buttons, submit forms, tables, etc.), I am
thinking of using blocks to insert components to each page. All
standard elements would be instances of form element classes. Calling
up these objects would generate customized html code.

Ex: a cbo box could be instantiated in a script via:
<p>Select Customer:</p><?php creatElement($cboName, $cboCSS, $cboVal,
$cboOpt, ..); ?>

Would such an approach be more efficient that the traditional
line-by-line approach wrt. debugging, maintenance, etc. ? (I really
dread mixing php and html.). While I like Smarty's templating approach,
it seems Smarty still requires linear coding to do code translation.

I visualize html pages in terms of grids where cells could be filled up
by html block components. Is this approach somewhat too fancy?

Thanks for any insights,

Mark

I create all my HTML through XSL stylesheets which makes building web pages
very easy. All my PHP code has to do is create an XML document with all the
data, and each data field contains instructions on which HTML control is
required for that field. This means that I spend less time in coding screen
layouts and more time in dealing with the important stuff, the business
rules.

Check out the sample application at
http://www.tonymarston.net/php-mysql...plication.html

--
Tony Marston

http://www.tonymarston.net
http://www.radicore.org

[Chung Leong]

David Haynes wrote:

I was thinking about this at a finer-grained level than you seem to be
in that I was thinking that msch-prv was thinking of automating the
common HTML elements rather than doing something more complex.
Well, it isn't really automation, since you still need to write the
function call. Basically you're trying to communicate to the computer
that you want an input element at that location. Using HTML as the
language for this purpose guarantees full flexibility. You don't really
gain much using PHP.
While I agree that some sites required a lot of "shimming", those are
also the sites that fall over with every browser upgrade and/or page resize.

True enough. Sometimes you just got to do what you got to do.

[David Haynes]

Chung Leong wrote:

David Haynes wrote:

I was thinking about this at a finer-grained level than you seem to be
in that I was thinking that msch-prv was thinking of automating the
common HTML elements rather than doing something more complex.

Well, it isn't really automation, since you still need to write the
function call. Basically you're trying to communicate to the computer
that you want an input element at that location. Using HTML as the
language for this purpose guarantees full flexibility. You don't really
gain much using PHP.

I was just thinking about the millions of times I have done something like:

if( ! empty($foos) ) {
printf("<select name=\"%s\">\n", $select_name);
foreach( $foo as $foo ) {
$selected = ($foo['bah'] == 'xxx' ) ? 'selected' : '';
printf("<option value=\"%s\" %s>%s</option>\n", $foo['value'],
$selected, $foo['label']);
}
printf("</selected>\n");
}

and was hoping that it could all be made simpler as something like:
$attributes = array('name' => 'foo');
htmlSelect($attributes, $foo);

in the hopes that the meaning for the page became clearer.

Maybe I'll play with this when I get a little more free time.

-david-

BTW: Why doesn't the foreach() handle the !empty() case? It would make
more sense IMHO.

[toddism]

Let me just say that of all the HTML doofers you can automate, <select>
is the one I have always made work.

I was just thinking about the millions of times I have done something like:
Exactly!


David Haynes wrote: Chung Leong wrote:

David Haynes wrote:

I was thinking about this at a finer-grained level than you seem to be
in that I was thinking that msch-prv was thinking of automating the
common HTML elements rather than doing something more complex.

Well, it isn't really automation, since you still need to write the
function call. Basically you're trying to communicate to the computer
that you want an input element at that location. Using HTML as the
language for this purpose guarantees full flexibility. You don't really
gain much using PHP.

I was just thinking about the millions of times I have done something like:

if( ! empty($foos) ) {
printf("<select name=\"%s\">\n", $select_name);
foreach( $foo as $foo ) {
$selected = ($foo['bah'] == 'xxx' ) ? 'selected' : '';
printf("<option value=\"%s\" %s>%s</option>\n", $foo['value'],
$selected, $foo['label']);
}
printf("</selected>\n");
}

and was hoping that it could all be made simpler as something like:
$attributes = array('name' => 'foo');
htmlSelect($attributes, $foo);

in the hopes that the meaning for the page became clearer.

Maybe I'll play with this when I get a little more free time.

-david-

BTW: Why doesn't the foreach() handle the !empty() case? It would make
more sense IMHO.

[Richard Levasseur]

ms******@bluewin.ch wrote:

I visualize html pages in terms of grids where cells could be filled up
by html block components. Is this approach somewhat too fancy?

Thanks for any insights,

Mark

Hmm...

Sounds like Java Gridbag, but for HTML.

Gridbag...or browser quirks and CSS...thats a tough one.

It would be handy to have a gridbag for html, sometimes, though.

[larry]

Working on my stuff I find programmtically building forms is best on
popups, checkbox lists, and radio lists, where you have multiple
options/selects), using arrays and such you can make it rather clean.
As for miscelaneous text fields most of that stuff as these people say,
is a matter of tweaking.

Larry

[Chung Leong]

David Haynes wrote:

I was just thinking about the millions of times I have done something like:

if( ! empty($foos) ) {
printf("<select name=\"%s\">\n", $select_name);
foreach( $foo as $foo ) {
$selected = ($foo['bah'] == 'xxx' ) ? 'selected' : '';
printf("<option value=\"%s\" %s>%s</option>\n", $foo['value'],
$selected, $foo['label']);
}
printf("</selected>\n");
}

and was hoping that it could all be made simpler as something like:
$attributes = array('name' => 'foo');
htmlSelect($attributes, $foo);
I usually do this:

<select name="something">
<? foreach($foos as $foo): ?>
<option value="<?=$foo?>" <? selected($val, $foo);
?>><?=$foo?></option>
<? endforeach; ?>
</select>

Where the selected() function echo "selected" if the two parameters are
equal. Doing it this way means I can very easily add in a javascript
handler, add an id, specify a class, add a empty item, and so forth.
The loop structure is also flexible. Sometimes I might use a for() loop
instead.

A function that can handle all the possibilities would be rather
complicated. Chances are you won't remember the parameters. This way,
it's just a matter of knowing your HTML. Friendlier for someone who has
to read your code too.
in the hopes that the meaning for the page became clearer.

Maybe I'll play with this when I get a little more free time.

-david-

BTW: Why doesn't the foreach() handle the !empty() case? It would make
more sense IMHO.

Do this:

foreach((array) $clowns as $name => $clown) { }

Null converts to an empty array.

[Peter Fox]

Following on from 's message. . .

I am about to embark on creating a mid-size web project that heavily
relies on db interactions.

Since most pages will contain recurring form elements (input text
boxes, dropdown boxes, radio buttons, submit forms, tables, etc.), I am
thinking of using blocks to insert components to each page. All
standard elements would be instances of form element classes. Calling
up these objects would generate customized html code.

Yes. Good idea.
Similar elements in similar positions with the screen zoned
appropriately.
The second part is getting the data in/out of the database.
Do this by connecting screen objects to the database model.

I've done this for a few years now and what I also have as a result is a
whizzo development system of objects I can stick together on a screen
with a few lines of code to do both screen and db.

Drop me a line(trapped) and you can have the whole code base ready to
run on mySQL.
--
PETER FOX Not the same since the porcelain business went down the pan
pe******@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>

[David Haynes]

Chung Leong wrote:

David Haynes wrote:

BTW: Why doesn't the foreach() handle the !empty() case? It would make
more sense IMHO.

Do this:

foreach((array) $clowns as $name => $clown) { }

Null converts to an empty array.

I hadn't thought of that. Good idea!

-david-

[Marcin Dobrucki]

ms******@bluewin.ch wrote:

I visualize html pages in terms of grids where cells could be filled up
by html block components. Is this approach somewhat too fancy?

I've had success with using PEAR::HTML_Page2 with a few other HTML_*
packages. For example, I have classes that handles Users, and has a
function "getForm". That produces a QuickForm object which I can then
dump into the HTML_Page along these lines:

$p = new HTML_Page2();
....
$u = new User(/* params */);
if ($show_form) {
$p->addBodyContent($u->getForm());
}
....
$p->display();

It took a while to hone this on a bigger scale, but now making GUI
changes is very quick and simple. It has an aditional benefit of not
having to buffer output because everything is inserted into the page
object, and its display is the last part of the script. So I never get
a "header already sent" problem. Anytime before $p->display() you can
re-direct, and do something else.

/marcin

[Richard Levasseur]

Marcin Dobrucki wrote:

ms******@bluewin.ch wrote:

I visualize html pages in terms of grids where cells could be filled up
by html block components. Is this approach somewhat too fancy?

I've had success with using PEAR::HTML_Page2 with a few other HTML_*
packages. For example, I have classes that handles Users, and has a
function "getForm". That produces a QuickForm object which I can then
dump into the HTML_Page along these lines:

$p = new HTML_Page2();
...
$u = new User(/* params */);
if ($show_form) {
$p->addBodyContent($u->getForm());
}
...
$p->display();

It took a while to hone this on a bigger scale, but now making GUI
changes is very quick and simple. It has an aditional benefit of not
having to buffer output because everything is inserted into the page
object, and its display is the last part of the script. So I never get
a "header already sent" problem. Anytime before $p->display() you can
re-direct, and do something else.

/marcin

IIRC, there is an option in php.ini to automatically buffer output
until flush() or the script ends, also avoid the header already sent
problem.

[Henk Verhoeven]

I agree with Peter, especially on the point that you should use objects
to produce the blocks. Objects are much more flexible then templates and
much more powerfull then simple html. You can make them smart and
adaptive so that you do not have to program a lot to use them. The
phpPeanuts framework is based on this principle too, combined with
simple html-mode php includes for the lay-out rich parts, see
http://www.phppeanuts.org/site/index_php/Pagina/26 for an explanation.

If you don't like the complexity that comes with such a framework, you
can take a look at the 'composition by inclusion and callback pattern',
see http://www.phppeanuts.org/site/index_php/Pagina/195 . The user
interface of the unit testing tool pnt/unit that is included in the
framework download is an example of the application of this pattern, it
does not use framework (except for a tiny not-OO function library).

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.

Peter Fox wrote:

Following on from 's message. . .

I am about to embark on creating a mid-size web project that heavily
relies on db interactions.

Since most pages will contain recurring form elements (input text
boxes, dropdown boxes, radio buttons, submit forms, tables, etc.), I am
thinking of using blocks to insert components to each page. All
standard elements would be instances of form element classes. Calling
up these objects would generate customized html code.

Yes. Good idea.
Similar elements in similar positions with the screen zoned appropriately.
The second part is getting the data in/out of the database.
Do this by connecting screen objects to the database model.

I've done this for a few years now and what I also have as a result is a
whizzo development system of objects I can stick together on a screen
with a few lines of code to do both screen and db.

Drop me a line(trapped) and you can have the whole code base ready to
run on mySQL.

[Chung Leong]

Henk Verhoeven wrote:

I agree with Peter, especially on the point that you should use objects
to produce the blocks. Objects are much more flexible then templates and
much more powerfull then simple html. You can make them smart and
adaptive so that you do not have to program a lot to use them. The
phpPeanuts framework is based on this principle too, combined with
simple html-mode php includes for the lay-out rich parts, see
http://www.phppeanuts.org/site/index_php/Pagina/26 for an explanation.

You're wrong on that. Just think about a little bit. How could a
hierarchy be more flexible than the free form nature of a language? If
you think so, try to formulate your next sentence in a tree structure.

The success of HTML was not a fluke. The marked up language is a simple
yet very powerful concept. That's why the interface of Mozilla is done
through a marked up language. It's also why the next generation Windows
user interface is based on a marked up language. You know those Vista
gadgets? Powered by HTML.

The widget library is an idea. Marked up language is the future.