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

[Paul Everitt]

Man, I love this thread. :)

Martijn Faassen wrote:
> 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.

As background, I've been on two really big consulting projects the last 
18 months that made Zope (Plone) generate XML representations of stuff, 
with UI generation done on the outside (XSLT in IIS, then Apache).

Getting Plone, AT, Five, formlib, and other parts of the stack to 
generate "good" XML has been a slippery endeavor.  I won't list the 
lessons learned on this, as I think it's a different topic.

On your last sentence, though...it seems like "Push Templates" are a 
direction others are interested in pursuing.  Guido's Templess, and 
Lennart's work getting that in Grok, is an example I believe.

Once you have a push model, serializing the template data into XML or 
JSON could be pretty straightforward.  (For people really committed to 
mashups, content re-use, UI validation, etc., they're probably going to 
want customized XML fragments in a specialized grammar.  But they know 
that and will do it for each project.)

Thus, I think the response to this point could be related to "Is push a 
first-class approach?"

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

I've gotten particularly interested in schemas (RNG+Schematron) to 
validate the contract between the model and the UI system.  As such, I 
usually want it to be easy to hack on the grammar of what's generated.

Thus, we've learned that we want to think in terms of XML fragments, 
some of which the system generates for you (<user>, for example) and 
some that are really unique to your project.  These all get stitched 
into a response document, and that too you want a chance to scribble on 
before it goes out the door.

Adapters and events could help make it easy to combine work done by 
others in assembling an XML doc, with stuff done for a specific site.

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

schema2xml sounds groovy.  Wish there was something similar for 
formcontroller state.

--Paul