[Grok-dev] Re: guidance for incorporating XSLT as alternative
cstrong at arielpartners.com
Thu Dec 20 09:00:52 EST 2007
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Grok-dev