Re: templating engine options

Tom Worster wrote:

thanks for taking the trouble to write your requirements. it made interesting reading.

and thanks for taking the time to read it! it was a big one.

i've questions on three points below... On 5/25/09 6:44 PM, "Nathan Rixham" <nrixham@gmail.com> wrote:

XSL Templates are near perfect, built for the job, and very powerful - but time hasn't favoured them well; and until (if ever) a wide spread adoption happens something else needs to fill the gap.

i don't know xsl well, but from what i read it seems to be about taking data from one xml document and putting it into another. that sounds reasonable except that the data that i want to combine with my template (either pushing it pulling) is in php variable state, not an xml document.

yes, transforming one document to another, using templates. works v well. php already implements xsl and its well supported using DOMDocuments and suchlike. however it's also supported on the client side in browser, which is a major selling point as you just send down the raw data formatted as xml and let the xsl stylesheets do all the work in the browser - so much weight off the server / app! to get the raw php data to xml is easy, there are already a tonne of array/object to xml converters available, and you can make one in a snap.

however, it seems that one could write a php template class that takes xslt template files and data from the script?

no need, http://php.net/xsl fully supported and uses DOMDocuments /DOMXpath the works. its all native to php 5 and above (and in php4 its http://php.net/xslt)

one thing i wasn't clear about with xsl is whether or not there's any output language dependence? could i write a template to produce an sql file, or an email in russian?

none that I know of - its a w3c recommended standard and imho one of the best written, practically everything you can think of is covered. if you have never tried xsl its really worth taking an hour or two out giving it a go, if you want some starting points just say. +xslt is supported by every major language, and most browsers like firefox, internet explorer, safari etc etc

Push vs Pull.

...

The freedom to be able to specify in template that... this is template module "latest posts", it is bound to the data view (or data provider) "latest posts(8)" whilst overall combining template (page) is comprised of modules x,y and z - here, here and here. ...really appeals to me; certainly in this scenario where you request (pull) from the application rather than make it all available. This way you only ever perform the business logic required for the information available. The counter part of making everything available incase it may be used is ridiculous (and makes me think coldfusion for some reason??). Architecturally this appears to be good - it's the presentation tier being a presentation tier, the logic tier knows nothing of the presentation tier and simply serves up what is requested. However thats only on the one side of the tier - on the other side we have a huge gaping hole where functionality should be (cache, compilation, delivery) etc, which would require another, as yet unknown layer (or 2). The abstraction and separation of concerns in this setup really appeals - but practically I'm not sure if the time spent implementing on a small or even medium sized project would be worth it. Still appeals massively though - pull makes more logical sense to me. Meanwhile, we have the first option, the way it's done, "push" the data - specify a template for that data and let template engine X do the merging. IMHO a clean, simple, lightweight implementation wouldn't be the hardest thing to make, and hundreds of apps are freely available all ready.

i don't think i follow you. it seems you're saying that there would be some kind of an intermediate level of data representation that a script can be invoked to produce from which different templates can produce different outputs. but i can't see any difficulty in achieving similar modularity and reuse with available push template schemes and appropriate division of code among include files. one includable script generates the intermediate view while others use various templates to use it in output. so i think i'm missing something in your definition of pull.

yup, the modularity can be easily achieved using push, but with push you have to effectively send everything that can be needed to the template engine, then the template can either show all of it, some of it or whatever. but with this method of pull, the template would be pre-parsed to see what was required, then the app would generate and provide only what was needed for that specific template. Thus saving you generating a load of unneeded data "incase" the template might want to use it. clear? if not just say. regards!