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

[Tino Wildenhain]

Am Freitag, den 22.07.2005, 15:06 -0400 schrieb Brad Clements:
> (leaving this on the zpt list)
> 
> On 22 Jul 2005 at 15:30, David Pratt wrote:
> 
> > That could be true. I am not sure when you to go from content to zpt to 
> > xml + xslt + css that it would be faster than something already 
> > rendered in xhtml + css (and js). With what I am thinking the way 
> > things may work in future, you may not have to worry about zpt at all 
> > and mod_python is very fast - at least this is where I see things 
> > going. There is even an effort called mod_zope underway.  My experience 
> > with xslt is that the templates can also be complex depending on the 
> > output. Docbook xsl come to mind for me and many people have not 
> > embraced xslt despite it being really great. It is just different and 
> > unfamiliar to many. I think what you are speaking of is very 
> > interesting, for sure and I do not want to discourage you in the least. 
> >   I remember the pipeline ideas BitFlux had for its CMS and also being 
> > excited about the possibilities that it brought to the table. There is 
> > all kinds of room for interesting ideas and exploration to satisfy 
> > anyone in zope ;-)
> > 
> 
> I think my point is being missed.
> 
> I'm suggesting TAL2XSLT as a "pre-processing step" for templates, not a 
> rendering step for each web request.
> 
> Yes, XSLT is difficult for some folks to understand. So, let them use TAL 
> and METAL to describe the layout of their pages.
> 
> Then, take those TAL/METAL  files and convert them to XSLT templates. 
> This conversion would be done only when the templates change, not on 
> every web request.
> 
> Then, on each web request some "xml blob" is created to serve as the 
> "TALES context" and fed to the previously generated xslt.
> 
> The "fed to xslt" step either occurs on the server (for old clients), or on 
> the client.  When done on the client, the client can cache the xslt.
> 
> Ultimately, you're having the client cache the un-rendered page template, 
> then on each request just sending back the appropriate TALES context.
> 
> --
> 
> Depending on how your templates are structured, sub-page components 
> could also be cached. For example, the infoset that describes the 
> navigation hierarchy for your site could be completely cached on the 
> client.
> 
> Example, if you have a "blog roll" that appears in a column on every page 
> of your site, that blog roll  would be cached on the client. It would not be 
> re-rendered of every web request.

I wonder what this buys you other then the well recognized XSLT-label.
XHTML+CSS where the XHTML is produced by simple and understandable TAL
can do all you would need. But thats just me...