[Zope3-dev] Pre-proposal: IDocument and friends

[Lennart Regebro]

From: "Lalo Martins" <lalo@hackandroll.org>
> Problem
>
>   A lot of data in a Zope site is too complex for an opaque blob
>   (such as the current "File" object) and too simple to demand
>   its own component class.
>
>   Of the "kinds" of data (using the term broadly, to mean
>   something that could or could not become a class) that have
>   enough structure to be a class, many share common structure
>   and features - a tree-like structure and the need for at least
>   one textual, human-editable representation, plus automatic
>   rendering to the web. This suggests these classes should
>   either use some common utilities or subclass a single base
>   class.

I do not understand what the problem is that you try to outline in this
"problems" section.

>   Requirements
>
>     1. Documents are primarily text,

If you assume images will be linked in from externally, then yes.

 >     with a tree-like structure.

And tables, which are not tree-like at all, and links.


Your proposal is not a bad idea, and a product like that could be very
useful. It can never be the only type, or even the basic type of document
for Zope 3. This is becuase the different representations will have
differences that can not translate between the different formats. A user may
want to do things in HTML that is not possible to do in your internal
format.
I know you don't think they should, but they want to, and then they can't
use your document. Instead docuemnts in Zope 3, as mentioned by Martijn
earlier, should conform to a common interface, but store the content in the
format they are to be displayed in.

However, I do think it's an interesting idea that could be very useful for
cross-media publishing, and would be an excellent add-on product for Zope.