[Zope-CMF] Compound elements status

[Jeffrey P Shell]

On 3/19/02 4:24 AM, "Florent Guillaume" <fg@nuxeo.com> wrote:

> Here's my take on CMFArticle, and the composite documents.
> 
> From what I see, CMFArticle is quite useful and could have its place in
> CMFDefault.
> 
> However it's not exactly a "composite" document, as defined by Jeffrey's
> description. In my opinion a real composite document has to have parts
> that are Types in their own right, and be really folderish in addition
> to contentish if it contains (as opposed to references) its parts, and
> also it has be intricately tied to the workflow.
> 
> The workflow part is really important: can a composite document be
> published and its subparts not be ? And vice versa ? What happens if I
> depublish and image inside a composite document ? What happens if I add
> an unpublished image to a composite document ? Etc.

This is why I'm not necessarily thinking of the CMF in my current design
phase.  In my design, I say that the workflow question is moot so long as
the parts are contained in the document.  I think that Parts (Elements) are
simpler than the current CMF Default content types, because they won't need
as many actions or a comprehensive set of meta data (ie, Dublin Core).
They're just parts of the greater whole, and that greater whole is
responsible for that data.

However, if you allow Parts to be embedded by reference, then the situation
does become more interesting.  The simple rule is - don't allow parts
embedded by reference.  We can get away with this rule for now because Zope
doesn't handle non-containment referencing very well by default anyways.
Zope 3 should address this, and Zope 3 will also give us an event channel.

[SNIP]
>>>>> The type itself should act as a single unit
>>>>> in workflow and searches, so that a search for a page does not bring up
>>>>> the components of which it is constructed, but the page itself.
>> 
>> I've always felt this should be a requirement too.  For the system I'm
>> designing, the Parts (the embedded components) are totally contained within
>> a PartContainer, which may also be a Part.  Ultimately, the root (which will
>> be the Document) asks its root PartContainer (of which there is only one) to
>> return indexable content, which might then walk down the tree of contained
>> parts and asking them the same question.  In the first go, the Parts can
>> never be linked to by an outside source.  The Document basically acts as a
>> sort of a Facade to the internal system, primarily made of the root
>> PartContainer Composite, keeping it all opaque to the outside world.
> 
> Does this mean that in your system the ZMI cannot see the individual
> parts ? Or are the parts not Types managed by the Types Tool ?

They are not types managed by the types tool, but they might be Parts
managed by the Parts Tool :).  My system is not being written for the CMF,
but it is being written for the possibility of the CMF.  :)  Basically, I'm
taking design ideas and patterns from my own past experiences, but also from
Formulator, ZPatterns, Zope 3, and OpenDoc.  So, it should be a fairly
pluggable system.

The ZMI would not see the individual parts, at least not as normal Zope
objects.  The management screens would be more geared towards a content
head.  Do you ever look at the contents of a Word document with embedded
images and spreadsheet parts as a folder?  It's just not a natural paradigm
in my opinion.  Everything may be stored as a tree underneath the surface,
but that's not necessarily the best view into the content.

Granted, the web has changed our views of documents, where all the objects
that get embedded into a page are separate objects in the file
system/database/universe, so maybe the paradigm has shifted some.  But I
don't think my target users right now think in those terms.

[SNIP]

-- 
Jeffrey P Shell 
www.cuemedia.com