[Grok-dev] Re: guidance for incorporating XSLT as alternative templating mechanism?

[Craeg Strong]

Martijn Faassen wrote:
>
> The thing to know about XSLT is that it can be used as a template
> language much like ZPT, not just as a transformation language.
>
> The idea is that instead of producing a dictionary with data, which
> most template languages take, XSLT needs some XML structure. It'll
> access this data using xpath. Hopefully the current template language
> integration already would allow for a strategy to pass the XML in and
> have the template language access it. But if not, we'll need to think
> about extending it somehow. I was hoping you could help me think about
> this topic of passing the data along.
>
> Perhaps however I'm on the wrong track and the original poster is
> aiming for something different?
>   
Your description is perfectly accurate. 
The only real complication with XSLT templating is that it requires XML 
rather than using python expressions directly like ZPT.

I like the idea of having a simple xml() method,
but for me the XML is also coming back from the browser since I make 
extensive use of XHR (AJAX)
calls.  Therefore I really want a way to transform python to and from 
XML easily. 
Maybe we need toXML() and fromXML() methods.   It gets complex because 
you are often dealing
with big graphs of objects. 

That is why I sometimes make the business objects themselves know how to
transform themselves to and from XML as a first step (self-adapters ?) 
and then later on on in the process I can
always decouple that via a simple refactoring if needed or desired.
As a matter of taste, I liken that to keeping unit tests inside the 
code, as a way to simplify maintenance.
The way I look at it, the XML schema and Python schema are on an equal 
footing, and must always be maintained in parallel for each domain class.
One reason I like ZODB so much is it means I have one fewer schemas to 
maintain (no SQL means two schemas instead of three)...

What I find interesting about Lennart's posting is that he is hinting at 
a very advanced approach that we sometimes take
for an application that has hundreds of HTML pages, where we logically 
define the layout of each page in XML
and then have a single canonical XSLT multi-stage pipeline that renders 
the page and binds the XML data.
But we don't need that kind of sophistication yet.  Maybe that could be 
done via a multi-adapter approach or something when the time comes.

--Craeg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/grok-dev/attachments/20071220/75d15bdf/attachment.htm