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@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.
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!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
