> 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 _______________________________________________ templates mailing list [email protected] http://lists.template-toolkit.org/mailman/listinfo/templates
