[ZPT] XSLT version of TAL, pushing caching to the client
tino at wildenhain.de
Fri Jul 22 17:34:16 EDT 2005
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
> 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...
More information about the ZPT