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.
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
- 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
- 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:
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
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
(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?
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -