[ZPT] XSLT version of TAL, pushing caching to the client

[David Pratt]

Hi Brad.  This sound pretty interesting. It seems from what I have been  
reading, there is no doubt that xslt will play big in future of zope  
and rendering content for users.  It is probably more of a matter of  
where it is going to happen. I think the wave will be to use zope a bit  
differently in the sense that you use zope for content management and  
you move content thru adapters and interfaces to a publishing process -  
an that the site is served by apache through mod_python.

In zope3, there will be all kinds of ways to adapt content in whatever  
flavor you want through adapters. So when you publish your site,  
perhaps this is most likely the xslt will happen so that through apache  
you are looking only at the rendered result leaving so fuss, no muss  
for client side applications.

I was also watching BitFlux with PHP when I was doing things in PHP.   
But now it is python all the way and I believe zope has a wonderful  
future with the potential of the zope3 architecture.

Regards,
David


On Thursday, July 21, 2005, at 11:18 AM, Brad Clements wrote:

> About 3 years ago I posted on this list asking if anyone else was
> interested in using TAL/METAL to produce XSLT stylesheets that could
> then be further processed.
>
> The folks over at Bitflux have toyed with this a bit:
>
> http://wiki.bitflux.org/Templates_TAL
>
> I've been playing with their TAL processing stylesheet (which they seem
> to have stopped working on)
>
> http://svn.bitflux.ch/repos/public/popoon/trunk/components/ 
> transformers/xsltal/tal2xslt.xsl
>
> And have started adding fill-slot/define-slot support to it.
>
> Also, trying to setup some unit tests.
>
> --
>
> All my Zope websites these days are more data driven then content
> driven.
>
> Each page "class" is a python script that returns an "XML context blob"
> with a stylesheet PI. That stylesheet then generates the HTML (usually
> on the client browser, but on the server if necessary).
>
> By page "class", I mean that many URI's are handled by a single
> pythonscript via traverse_subpath handling, and each script handles a
> specific class of "page types".
>
> The xslt stylesheets themselves also have xsl:include statements that
> work, sorta like metal macros.
>
> With further use of the document() function in the xslt stylesheets,  
> 99% of
> browsers can cache individual page fragments in the client's browser.
>
> This approaches the ultimate goal of the ESI (Edge Side Includes)
> specification.
>
> http://www.esi.org/index.html
>
>
> Throw into that mix AJAX-style interfaces (sorry for buzzword use), and
> the usefulness of XML-backed Zope sites increases dramatically.
>
> Suddenly my RESTful data sources can be exposed, either by
> compositing into the html page directly during HTML generation via the
> document() function.. Or dynamically via XML-HTTP requests, or both!
>
> Also, where appropriate, my data sources can render their output as XML
> or javascript literal or javascript arrays (though the later is  
> client-side
> javascript specific).  Mozilla's transformix engine isn't very fast,  
> so for
> google-suggest style interfaces sending over javascript arrays is  
> better
> than sending XML.
>
> Though in a pinch, I also have used an XSLT file to convert XML back
> into javascript literal format on the client. This works until E4X is
> implemented in client browsers:
>
> http://www.ecma-international.org/publications/standards/Ecma-357.htm
>
>
> --
>
> For my clients, using XML/XSLT as the basis for web-site architecture
> has dramatically simplified my site designs, while simultaneously
> increasing the flexability in interface creation through the  
> composition of
> data sources and templates (xslt).
>
>
> Additionally, offline back-end processing via XSL-FO is now possible  
> with
> hardly any additional effort.
>
> --
>
> But back to ZPT and XSLT.
>
> In ZPT, the TALES context space serves as the root of the data source
> tree that is used to expand TAL elements.
>
> ZPT sheets can be tested in-situ as they are being edited by clicking  
> on
> the test tab.
>
> For TAL/XSLT, the context space comes from the "XML context blob"
> (with the launch point stylesheet PI).
>
> TAL to XSLT requires a pre-processing step, where the tal document is
> converted to xslt. Perhaps this will be a three-step process if we  
> want to
> make METAL expansion a distinct phase (to ease previewing and editing
> of  the TAL page).
>
>
> This makes working with TAL/XSLT at least a  three-step process.
>
> 1. Metal expansion
>
> 2. TAL to XSLT
>
> 3. Final rendering of "XML context blob" to XHTML (or whatever). This
> step usually occurs on the client browser.
>
> Different XML context blobs can use the same XSLT stylesheet. So in
> some respects this is somewhat similar to Zope acquisition, where the
> "data context" can be applied to a "template context" through the
> arrangement of the requesting URL.
>
> --
>
>
> So, is anyone interested in TAL to XSLT?
>
> I guess I should have blogged about this instead.. Can't remember where
> I left my blog...
>
>
>
>
> -- 
> Brad Clements,                bkc at murkworks.com    (315)268-1000
> http://www.murkworks.com
> AOL-IM or SKYPE: BKClements
>
>
> _______________________________________________
> ZPT mailing list
> ZPT at zope.org
> http://mail.zope.org/mailman/listinfo/zpt
>