On 10/18/06, Igal Koshevoy <[EMAIL PROTECTED]> wrote:
Thomas,
Most web toolkits can decorate pages using a site-wide template. These
decorators programmatically intercept pages and transform their contents
-- which is the opposite of the SSI model where each page has to
manually include a snippet of code (e.g. a header). The decorator
pattern is superior to SSI because it produces clearer code, lets you
quickly decorate existing pages, and enables you to make huge changes to
your site layout without having to change each page's SSI/include/etc code.
Good examples of such decorator tools include Rails layout [1][2]; Perl
HTML::Mason autohandler; PHP-Mesh; and Java's SiteMesh, Tiles,
FreeMarker template macros, and others. I haven't used PHP-Mesh yet, but
all the others are excellent.
I would argue (as a long time user) that tiles is does not quite fit
the decorator pattern, but... also, php-mesh, from the sounds of it,
is somewhat neglected.
Anyway, I'm already with you on the decorator-beats-SSI wavelength.
Personally, I'd love to be able to use SiteMesh, but I don't want to
overhead of a java stack when nothing else on this server(s) will be
using java in the near-term (long-term, mostly likely, too).
Although it's possible to build a high-level filter using XSL or a
parser like Hpricot, I have to agree with the others that this could
turn out to be a curse. In most cases, it would be easier and more
maintainable to select the decorator tool that best integrates into each
app's framework, and maintain a single template per program.
The whole point of the post was to not have to use a template per
program. I'm already doing that and seeing maintenance problems.
Especially when some of my less technical colleagues need to be able
to edit these templates.
_______________________________________________
PDXRuby mailing list
[email protected]
IRC: #pdx.rb on irc.freenode.net
http://lists.pdxruby.org/mailman/listinfo/pdxruby
