[Zope-dev] Any interest in a set of Zope products to support CVS-versioned, XML/XSLT-based Zope development?

[Romain Slootmaekers]

> In our opinion, Zope
> is about a year or two ahead of where these guys are in many respects. 
>  Kudos!

When I asked the tomcat mailing list for Zope like functionality in tomcat
(some year ago) nobody even answered. The product probably wasn't known or
nobody saw the possibilities. I still think cocoon rocks, and 
session managament in Tomcat is way better than in Zope. The problem is
that Tomcat demands more skills from the webbies. and Zope allows easy
maintainance of 'live' sites, on site. Anyway,
 
> 
> The main problems we faced while moving to Zope were these:
> 
> - how to support version control, branching, merging, tagging, etc. 
> etc.  (we use CVS)
> - how to support our XML/XSLT-pipeline based document publishing 
> paradigm (cf Cocoon2)
Having moved ZZICT towards zope from jsp. we faced the same XSL/XSLT
problems. I often wondered: how come they have xml-rpc but not XSLT?


><snipped>
> XMLDocument:
> (Sorry for the name clash).      Inherits from CVSFile.    Has a notion 
> of a "transformer" property that points to an XSLT transformer.
> This enables it to be rendered automatically into HTML when __call__ or 
> index_html is called.    The underlying XML file
> can either be external or not.  The XMLDocument object represents the 
> entire file, as opposed to the parsedXML stuff that explodes
> a single document into multiple Zope objects for each XML node (correct 
> me if I am wrong...)

We developed more or less the same thingy: a ZZXML product which is an XML
file which upon rendering can be transformed by any number of XSLTs. the
way the XML and XSL are linked is that of the XSLT spec: 

<?xml version = "1.0"?>
<?xml-stylesheet href="....xsl" type="text/xml"?>
...

I personally hacked in into a Zope 2.4 with the python xml.xslt and
xml.dom.ext packages and some 200 lines of glue code.

The problems with the thingy are:
- xml authoring :the xml documents are only editable as text
- xslt is not context sensitive. fi I'd like to be able to apply different
  style sheets for (fe) different authorization roles
- for some reason the webbies don't really like an XML/XSLT pipeline,
  because it is rather difficult to get the separation of concerns right.
  (fe content:XML only, first style sheet: structure of page second style
   sheet: markup elements , third style sheet: browser specifics aso)
  Web publishing still remains rather hard. 

> There is lots more to do, but we do have initial development versions of 
> all three working in the lab.   Is there interest in this kind
> of Product?   Would it be considered heretical? ;-)   Are others working 
> on the same thing?
In short: yes, donno, yes.

Romain.