[Zope-dev] XML Roadmap (Fwd: [XML-SIG] Hello)

[Michel Pelletier]

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