[Zope-CMF] Compound elements status

[Florent Guillaume]

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.

[more comments below]

Jeffrey P Shell  <jeffrey@cuemedia.com> wrote:
> On 3/18/02 4:15 PM, "seb bacon" <seb@jamkit.com> wrote:
> > A separate design consideration is that it would be nice to be able to
> > recursively compose components.  What I mean by this is the following:
> > suppose you have a type which has two fixed slots, "image" and "text".
> > These are displayed in the default action with the text on the left and
> > image on the right.  Wouldn't it be nice to be able to add these two
> > elements as a single "textandimage" component to another template?
> 
> I think this would be nice.

Agreed.

> > Another consideration is that it would be nice to be able to use any
> > existing Types as components without having to tinker with their source
> > code: it should be possible to create new 'articles' (I call them
> > 'templates') through the web.

I agree with Seb here.

But the difficult part about this is that currently CMF has a notion of
workflow that's intricately driven by the CMF Type. This has to be made
more flexible to accomodate the kind of nonlocal workflows that we need.
I have some thoughts about that, but I am too pressed by other projects
right now to do more than wave my hands :-)


> >>> 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 ?

> However, I've seen and worked on a system where every Part could be shared,
> which actually makes sense for larger systems.  But the complexity goes up
> quite a bit.  Fortunately, on that system, the content management side and
> the "public" side were kept separated from each other, with content being
> pushed out of the content system at approval time to a place where the
> public facing system (which was running different software) could get at it
> and present it all bound together appropriately.  If it weren't for this
> separation, designing for security and workflow I think would have been
> harder (what happens when two stories share the same picture, and one of the
> stories gets pulled from the site for re-editing?).  However, I think a good
> template definition system could allow all sorts of rules to be placed on
> the slot definitions about how to propagate events to shared parts.

Yes, some kind of workflow events could be needed, or a mechanism
general enough to be able to set a worfklow policy on an aggregate of
objects ("publish/depublish all my parts whenever I'm
published/depublished, forbid addition of an individual part if I'm
published", "allow private parts to be added even when I'm published",
etc.)


Florent
-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 10  http://nuxeo.com  mailto:fg@nuxeo.com