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

[Adrian Hungate]

I'll leave the CVS to others, XML stuff is right where I am looking at the
moment. My XML kit is not "standards" based (And anyone who has spoken to me
about XMLKit will know that I don't like the current SAX/DOM implementations
in python as they try to make Python think like Java...). I have been
looking to greatly improve the proccessing in my XMLDocument because it is
currently both counter-intuitive and clumsy to use. I may have
misunderstood, but my XMLFile and XMLProxy objects my provide some of what
you were taking about with the Zope access to XML both inside and outside of
your Zope.

Maybe we can move XMLKit in the directions you are talking of aswell?

The two criteria that I have are:
1) The code needs to be Python, not C (For now at least) for the platform
independance. (A number of Zope products I would love to use will only run
on one platform and I need complete platform independance for most of my
installations).
2) The product needs to be easy enough to use that a someone who is not an
XML-guru can use it to good effect.

Adrian...

--
The difficulty of tactical maneuvering consists in turning the devious
into the direct, and misfortune into gain.
- Sun Tzu

----- Original Message -----
From: "Craeg K. Strong" <cstrong@arielpartners.com>
To: <zope-xml@zope.org>; <zope-dev@zope.org>; <cstrong@arielpartners.com>
Sent: Wednesday, October 31, 2001 2:30 AM
Subject: [Zope-dev] Any interest in a set of Zope products to support
CVS-versioned, XML/XSLT-based Zope development?


> Greetings!
>
> We at Ariel have recently started using Zope and, needless to say, we
> are enjoying a large increase in productivity
> compared to our previous Apache-Cocoon2-Tomcat-Servlet-dbXML-Java
> environment.   In our opinion, Zope
> is about a year or two ahead of where these guys are in many respects.
>  Kudos!
>
> 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)
>
> We have seen several efforts underway to address these issues within the
> Zope community.   We have gone a slightly different
> direction, but hope to contribute to these efforts in some way.     In
> our environment:
>
> - multiple author/developers work on the same documents at the same time
> - we work on content for several clients at the same time
> - web pages are cobbled together from content pulled from several XML
> documents, according to a PagePolicy
>    (similar to the way articles are collected and pasted into a
> newspaper page).
> - the PagePolicies can be changed independent of the underlying content
> (header-body-leftmargin-footer, header-body, etc)
> - all content is in XML, transformed into HTML/DTML by XSLT.
> - we use lots of tools other than Zope, so we want to keep our content
> in XML, not pickled Zope objects. (hold the pickles ;-)
>
> In order to make all this work, we created three Zope Products:
>
> ExternalFile:
> Points to a file in the filesystem.  Unlike ExtFile, it is not copied
> into a repository directory, but remains "in situ"
> Behaves similarly to a symbolic link in UNIX or windows shortcut.
> Metadata stays in Zope, but content stays in the file.
> index_html and __call__ return the content as if it were a real Zope
> object, so Zope doesn't know the difference. :-)
> Due to permissioning and other possible problems, this is probably only
> appropriate for development, not production.
> In future, we hope to add an option to copy in the content to ZODB,
> essentially converting it to a DTMLDocument.  At that
> point we will probably rename the class "ExternalizableFile"  more on
> this later.....
>
> CVSFile:
> inherits from ExternalFile.    Same thing, but the file is assumed to be
> inside of a CVS sandbox.   Includes buttons for doing
> normal cvs commands.   Sandboxdir is stored in a cookie, so each
> developer can access his own sandbox via THE SAME ZOPE OBJECT.
> That is, all developers can share a single Zope server but each see
> content from his own sandbox.   (play in your own sandbox :-)
> This avoids the locking issues and other problems inherent in things
> like CVSwebClient.   It also enables the content to
> stay "native" rather than becoming a Zope extract like in
> ZCVSMixin/ZCVSFolder.
>
> 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...)
>
> 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?
>
> Thanks!
>
> --Craeg
>
>
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope )
>