Perrin Harkins writes:
> The same template? How does the layout manager help with that? Does it
> modify the template? It would make more sense to me if this were a sort
> of abstraction to factor out common layout ideas from multiple
> templates.
I think we're miscommunicating. I'm talking widgets, and you're
talking templates.
A layout manager is a bit of a red herring in mod_perl. I was simply
trying to explain how they came to be and why they make sense. In
GUIs, the layout manager is responsible for placement when the window
is resized. In mod_perl, it plays a lesser role, because the browser
does most of the work (thank goodness).
Templates and widgets are pretty much the same thing (see discussion
at end). It's how you use them that makes a difference. We have a
String widget. You could just as well make a string template. It's
not natural in template languages to wrap every piece of text in a
string template, however.
A String widget/template allows you to control the rendering of all
fonts dynamically. If the String widget/template sees the incoming
request is from IE5+, it doesn't render the font if the font is the
same as the default font. The Style widget/template renders the
default font in a style if the browser is IE5+. This avoids the
stylesheet bugs in all other browsers and gives 90% of your users who
are running IE5+ a much lighter weight page.
It's cumbersome to do wrap all text in string templates, because the
calling mechanism is verbose. Most template languages I've looked at
only support named parameters.
Widgets can have named parameters, e.g.
String({
value => ['User.first_name'],
string_font => 'my_first_name_font',
});
but it is much more convenient to use positional notation:
String(['User.first_name'], 'my_first_name_font');
The way I like to think of this is that HTML corresponds to machine
language. Templates correspond to assembly language. Widgets
correspond to structured programming. You can program everything in
assembly language, it's just more cumbersome. This is why people
invented macro assemblers, but there is still a significant difference
between building a system in C or Macro-11.
This is why a layout manager is a natural concept to me. It's a
widget which does something with the results of other widgets. What's
cool about HTML is that you can do this "post draw", i.e., after the
widget renders a child, it can look at the result to determine its
next action. For example, the String widget can escape the output of
its child. I haven't seen this in template languages and rarely in
GUI toolkits.
Rob
