[Zope3-dev] Axe DTML Document

Tue, 18 Dec 2001 11:01:05 -0700

On Tuesday, December 18, 2001, at 07:14  AM, Casey Duncan wrote:

> On Tuesday 18 December 2001 09:00 am, Paul Everitt allegedly wrote:
>> We *nearly* did this for Zope 2.5.  We wanted a Document 
>> Document, not a
>> DTML Document.  A Document that acted more like CMF Document: got its
>> formatting imposed on it (rather than requiring includes at the 
>> top and
>> bottom), focused on content rather than programming, etc.
>>
>> When we realized what we were getting into, we deferred.  Namely, we
>> didn't want to invent a temporary Document to compete with CMF 
>> Document
>> when it was time to do a Zope3 Document.
>>
>> So now it's time for Zope3.  We need a Document.  We need someone to
>> make a Document.  I nominate Casey. :^)
>>
>> --Paul
>
> Hey, cool a project for Zope3!
>
> From experience how much of the CMF Document is applicable, or how 
> close is
> it? Is this something for the fishbowl first?

Quite a bit of it is applicable.  Internally, we have a nice evil 
mixture of CMF Document and DTML Document that does some fancy 
round-trip-trickery for HTML Editing purposes (when edited over 
FTP/WebDAV, you get the <html><head><title><body> tags in place of 
'var standard_html_header', but those get lobbed off during save 
and get wrapped in everyone's favorite dtml-var calls.  When edited 
through the web, you do get the standard_html_header/footer joy).  
The nice things about it are that (a) <meta> tags get turned into 
properties which can then be indexed (it's also catalog-aware), (b) 
end-customers can upload and edit documents relatively easily, and 
(c) WE can edit and tweak in some DTML where occasion demands using 
the same system.

When a CMF Document is edited, the text handling is passed off to 
another system.  Currently, it's not the most flexible system, but 
it could be componentized fairly easily.  Depending on the type of 
document uploaded, it gets handled by either Structured Text or the 
HTML parsing/handling tools.  The data that is expected to be 
returned from Document#handleText() is: Headers (mapping to dublin 
core properties in the CMF), Body (the editable content body - raw 
structured text, or the html inside the <body></body> tags), Cooked 
(the cooked text, such as rendered structured text), and Format (a 
string indicating the format of the text, such as 'html').  So, 
unlike DTML Document, CMF Document renders its inner content at 
edit time, which basically caches the HTMLized structured text.

Something I've been wanting to do for a while is to find the proper 
interface for TextHandlers, and to componentize them to be managed 
by some tool (ie, 'portal_text' or something).  I think any design 
of a new Zope3 Document should follow this pattern.  By having 
different handlers available, we *could* even keep DTML open as one 
of the handler options...

Jeffrey P Shell, jeffrey@cuemedia.com