[Grok-dev] Re: guidance for incorporating XSLT as alternative
paul at zeapartners.org
Fri Dec 21 12:38:19 EST 2007
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
> 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
More information about the Grok-dev