> The obvious usage of it would be in an Ajax style application
Why in the world you'd want to use a text-based pattern matching
template system with that when you have all the power of the Document
Object Model at your disposal I do not know. It would make most sense
to me to create your own DTD and use an XML based system, I don't see
any reason why you couldn't do say (not that I'm an XML wizard or
anything):
<include src="http://..";> or <var value="whatever">
and create a nice simple parser for it..
> This is easier to do with XML, but having a TT-style approach may be
> an alternate approach for people who don't like XML.
Maybe, but since the client can parse html and xml very quickly and
efficiently, but has little to offer to assist you in parsing the text
yourself, it would seem to me to be a waste of a perfectly good
opportunity just because somebody "doesn't like XML"
And I still think client side templating is a daft idea.. Server-side
templating systems such as TT2 have grown with the assumption that
including another file is a relatively cheap and reliable process, and
using seperate template files is basically how they provide
modularity.. but the situation is very different client side, fetching
a new template is a slow complicated procedure that may or may not
work, and you don't have the luxury of being able to call on a
CPAN-like library of code to do stuff like parse text reliably...
PS. I absolutely detest the phrase "AJAX". It's horrible! I understand
people's need to wrap up a collection of technologies in a nicely
named package so they can talk to their boss about it without their
eyes glazing over, but come on, that one was taken years ago by the
brand of soap that my first school used to use to clean the toilets.
--
Dan
|
