thanks for taking the trouble to write your requirements. it made interesting reading. i've questions on three points below... On 5/25/09 6:44 PM, "Nathan Rixham" <nrixham@xxxxxxxxx> 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. however, it seems that one could write a php template class that takes xslt template files and data from the script? 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? > 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
