Patrick Phalen wrote:
Basically, I'd like to "plug" the XML/XSLT part in the Zope site-building process. Fundamentally, Zope's DTML resembles XSLT, but as an INRIA employee, I tend to prefer XSLT and the standards my colleages are working on ;-).
What a coindcidence!
In the end, is this doable? Are there any missing parts or tools in this chain?
Yep. I'm currently prototyping a new component for Zope called MFI (Multi-Format Interface, I needed a good TLA). If you can follow my stream of conciousness, MFI realizes two very cool ideas: 1) Objects that want to contain 'content' in various 'formats' 2) Objects that want to override their behavior at 'call time' (ie when viewed by the browser) A brief description of the achetecture is: Objects that wish to use the MFI subclass two classes, MFI and Behavior (there is another class, Cache, which realizes smart caching with objects, but that's strictly a performance issue). MFI provides the framework for objects to use one of any pluggable type of format. Currently, I am realizing 4 formats: NULL (does nothing to the content) HTML (does nothing for now, but in the future may parse out HTML properties/entities) STX (structured text, it's a Zope thing) XML (parses content into a DOM tree) So there are two actions done for each format type: At 'format' time, the content is parsed and transformed into 'formatted content' for NULL, HTML and STX, this currently does no parsing. XML is parsed into a DOM tree. At 'call' time, the content is returned to the caller (typically a browser) in a default way, NULL and HTML do nothing, STX renders the structured text into HTML, and XML is returned to the browser as XML. This is the 'default behavior'. All 'formatters' can specify both the 'format' and 'call' actions. The call action specified by a format is the default behavior. Now, an MFI objects that also subclasses Behavior can specify a number of plugable behaviors that replace the 'default behavior'. If no pluggable behavior is specified, then the default behavior for the format is used. Currently, there is only one pluggable behavior, DTML Method. It would be trivial however to include any other method type, like External Method, PythonMethod (by Evan Simpson) or, as I see it, an XSLTMethod (that only makes sense in the context of an MFI object that uses a format that results in a DOM tree-like object). So, here is a scenario I think you'll like: Create an MFI document and fill it with XML, specify the format as 'XML'. Select 'XSLTMethod' as the pluggable behavior, and type your XSLT code into the behavior text area. Now: When the object is 'called' (from a browser, let's say) the XML content is transformed by the XSLT into whatever you want. You could also have specified 'DTMLMethod' and written some DTML that called DOM methods etc. The beauty of all this is that it's absolutly extesable and fits nicely into the Zope framework, for example, methods can be acquired by behavior just like other methods in Zope can acquire each other, therefore site-wide behavior can be automaticly specified and overridden on a behavior by behavior basis. Entire behavior frameworks can be written in a combination of languages (DTML, XSLT, python) and mixed and matched into a variety of content in a combination of formats (plain text, HTML, stx, XML). -Michel