[Grok-dev] Re: guidance for incorporating XSLT as alternative
faassen at startifact.com
Thu Dec 20 02:10:40 EST 2007
cstrong at arielpartners.com wrote:
> I would love to get a few pointers on how to go about adding XSLT as an
> alternative templating mechanism.
> My plan is to always emit and consume XML via the Amara library.
Hah, Amara?! :) I'd allow XML generation with any library at all. XML is
As to XML consumption, I vouch that I'll implement an lxml-based version
of whatever you come up with.
Anyway, Lennart Regebro needs to be in this conversation, as I hope we
can push the templating language mechanism in Grok 0.11 work for XSLT too.
> Sometimes the XML will be sent to the browser which will use
> Other times the XML will be transformed via XSLT on the server side.
> I am aware I am sacrificing efficiency for the sake of portability and
> I like the idea of adding xslt templates alongside zpt and genshi using
> another file extension (e.g. ".xsl")
If you have both browser-based XSLT and server-side XSLT you might want
to consider two extensions and thus effectively two template languages.
The alternative is some global mechanism where you can switch
transparently. The advantages of the former approach is that
browser-based XSLT probably has different constraints than having
server-side XSLT, so treating them separately might not be too bad. The
drawback is that, well, you're treating them separately.
> Perhaps the XSLT template mechanism knows it needs XML so it requests a
> suitable adapter?
We could assume that the views involved will return XML structures,
perhaps when a special method on them is called. That could also be done
with some form of adaptation technology, but since views are already
adapters I'd think requiring a special 'xml()' method would already be
enough. Anyway, this is the trickiest part to define. What would such a
view look like?
More information about the Grok-dev