[Zope-CMF] Z3WCM: Future of Document

[Jeffrey P Shell]

On Thursday, October 10, 2002, at 01:36  AM, Paul Everitt wrote:

> Jim and I have been talking about how to get the Z3WCM (Zope 3 Web 
> Content Management) effort moving.  I'd say "The Future of Document" 
> is a pretty important part of it, but it's also really squishy to get 
> a grip on.
>
> One approach that has been mentioned in previous proposals is to make 
> Document dumber, delegating harder or more specialized work to other 
> components.
>
> Do you folks think that your discussion here approaches that direction?
>
> If you're interested enough to reply, please change the subject line 
> to something like "Z3WCM: Future of Document".

The FDoc product that I swear I'll make some time to put together an 
early release of soon might be interesting to look at.  It's a 
free-form compound document, built out of parts.  The smartest/dumbest 
part is the 'text/*' part, because it does delegate text handling off 
to very small Handler components.

The TextPart basically uses its minor mode to decide which handler to 
use at edit time.  It gets the handlers out of a Handler registry, 
based on name.  The two I have implemented right now are HTML (using 
modified SafeHTML/Stripogram code) and Plain Text, which just runs its 
contents through DTML's newline_to_br function.  One that I really want 
to do is a 'python' handler that uses py2html/PyFontify to colorize 
Python code for technical documents.

In FDoc, the responsibility of a document is minimized to basically 
containing a root PartContainer - a part manager that handles the 
organization and querying of the Parts that make up a document.  As 
such, when I did the CMF implementation (for a customer) of a compound 
document, the code was very small - most of it spent living up to the 
expectations the CMF has of a content object.  An FDoc Document is 
basically a small shell with a simple expected Interface so that it can 
be adapted to different environments easily.  A benefit I recently 
noticed about this design is that it actually lets me design documents 
with multiple forks - either multiple languages, or something like Mac 
OS Resource Forks.  In addition to the 'root' PartContainer, I could 
use a 'metadata' PartContainer which could include icons and thumbnails.


TextHandler Interfaces:
class IHandlerResult(Interface):
     """
     IHandlerResult objects return IHandlerResult objects, which are
     simple records that any text managing utility can use.
     """
     source = Attribute("The web-editable source code.")
     cooked = Attribute("Rendered (cooked) code, used for display")
     fullsource = Attribute(("The full source of the text, to be 
presented to "
                             "non-web clients"))
     headers = Attribute("A mapping object of headers/values")

class IHandler(Interface):
     """\
     IHandler objects process text and return an IHandlerResult object.
     """
     def handle(text):
         """\
         Processes the incoming text and returns an IHandlerResult
         object.
         """

Document Interface:
class IDocument(Interface):
     """ The document class.

     Document's are the root of a compound element tree, containing
     a single PartContainer (root) and offering access to services
     needed for contained parts.
     """

     def document_root():
         """ Returns the document object itself """

     def getPartRegistry():
         """ Returns the part registry to use for this document """

     def getRootPart():
         """ Returns the root part of the root document """