Thomas Lockney wrote:
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.
Ah, I misunderstood. The comments about SSI and manually including
headers in this thread gave me the mistaken impression that decorators
hadn't been considered before diving into these more complex approaches.
In that case, I'm wondering if you're asking for too much. If you must
have a cross-application template for consistent look-and-feel that's
easy for your colleagues to work with, you'll probably have to rewrite
all your apps to emit consistent HTML that it can parse directly, e.g.
they all must use H1 to indicate a heading rather than throwing out
DIVs, TDs or whatever else. Rewriting apps can be quite a chore and I
understand why you want to avoid that.
But if you want to leave the apps untouched, you'll have to write a
bunch of conditionals to make sense of all the different formats these
apps can produce, which can be difficult and will likely become a
maintenance nightmare. Worse still, your colleagues probably won't be
able to work with this code directly, so you'll have to hide it behind a
friendlier template, which creates another set of issues.
What I'm getting at is this: what's more important to you -- easy
templates, or not having to rewrite apps? Because I'm not sure you can
get both unless you keep your expectations low for keeping the
look-and-feel consistent.
I would argue (as a long time user) that tiles is does not quite fit
the decorator pattern
I was generalizing, but you're right, Tiles is a layout tool and not a
true decorator like the "mod_transform" tool that Devin just posted a
link to. I agree with him that XSLT is purpose-built for this sort of task.
I've really enjoyed working with Hpricot while writing Rails integration
tests, but I doubt it can compete with the performance of a good XSLT
implementation. Given that all your pages will be passing through this
filter, performance might be a significant concern.
-igal
_______________________________________________
PDXRuby mailing list
[email protected]
IRC: #pdx.rb on irc.freenode.net
http://lists.pdxruby.org/mailman/listinfo/pdxruby
