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

[Martijn Faassen]

Hello,

Craeg Strong wrote:
[snip]
> 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.

Do you mean that your browser is sending XML to the server?

> Maybe we need toXML() and fromXML() methods. It gets complex because 
> you are often dealing with big graphs of objects. 

Yes, I am not sure there is a general solution to this. I can see there 
being a bunch of utility functions that can help translate object graphs 
(especially simple dictionaries and lists and so on) to XML. There's 
also the schema2xml package I wrote about, which can take a 
schema-defined content object and transform it to XML (or back). This 
works quite nicely.

> 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.

They don't have to know themselves, right? You can just define normal 
adapters to do this. Some other code will then use these adapters. Oh, 
perhaps you mean this: if your object implements the interface you want 
to adapt to, any adaptation request to that interface will return the 
object itself. That way you can start out putting the knowledge in the 
objects and factor it out later. Sure, that is a reasonable approach as 
well. Note that in Grok it's so easy to create adapters it's almost as 
simple to write them right away.

> 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)...

If you use schema2xml you don't really need an XML schema, you can just 
define zope.schema schemas.

> 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.

I also see these as separate approaches. The pipelining story is very 
interesting, and that's why Lennart thought I was talking about this; we 
talked about it before. In this case we have a more modest goal where we 
simply want the ability to use XSLT templates like we do ZPT templates. 
The only requirement is *some* way to generate the XML that goes into 
the XSLT templates.

I think we should start with a simple view infrastructure. The XSLT 
templating solution would call the xml() method on the view to get the 
XML representation for whatever content object is being displayed.

The developer can implement these xml() methods themselves for each 
view. Most likely he will do this using some helper functions as I 
described above.

Now we can build things on top of this infrastructure. Instead of 
creating a new xml() method each time, we can have a special kind of 
view that implements xml() already, and uses the adaptation 
infrastructure as you describe, or something like schema2xml.

Regards,

Martijn