[Zope-CMF] Compound elements

[seb bacon]

I'd like to ask about the status of compound documents,
since they are scheduled for CMF 1.2, which I understand is forthcoming
(sort of).

In particular, I've done a lot of work on the concept already, so it
would be a shame not to discuss it a bit more first.  I don't think my
implementation is very good, but it works.

Here are some thoughts in no particular order (warning - long and
convoluted): 

1) The interface.  I put the 'Slots' in a tab of the TypesTool ZMI.
   I created a new TypeInformation which knows how to add and remove
   slots on the content in question, but of course only certain
   Types can be composite.  I wondered whether these types should live
   in their own tool rather than mixing with the normal types.
   Has anyone else thought about this?

2) The location of components.
   Should components be attributes of compound elements?  I made
   my compound elements be ObjectManagers, but I'm not convinced that
   the folderish containment paradigm is the right one - ideally
   perhaps this would work with Ken's OrganizationObjects, but these
   are some way off, I presume.

3) Event distribution.
   Jeffrey identifies workflow as an example of the kind of event
   which needs to happen to a compound element and its components
   collectively.  The other obvious thing is indexing.  Less obvious,
   but potentially quite powerful, is the action that the compound
   element is being called with (see thought number 5, below).
   A problem with this is that in order to have a two-way event
   channel between the compound element and the component, both must
   be special content.  The consequence is that you won't be able just
   to drop a Document into a compound element slot; you'll have to
   mixin the extra functionality, or something similar.  One solution
   is to make PortalContent be CompoundAware by default.  
   
4) Compound elements should be recursively composed.  
   You could make a compound element which is an image and a link, and
   place that in turn into a compound element which is a page of
   image/link combos.  By this token, PortalContent CompoundAwareness
   should enable all content to be compound elements *and* components.
   Is this feasible?

5) Actions distributed to components.
   I really like this idea, though I'm struggling to think of an
   example of where it would be useful.  In the system I'm working on
   at the moment, the 'edit' action causes each of the components to
   display their 'edit' views too.  (I can then make text boxes become
   textareas, etc, giving a nice WYSIWYG editing interface).
   As part of a compound element's Slot information, it also stores a
   mapping between the container's actions and the each component's
   action.  

   For example, I might have a compound element called
   PlainTextTemplate, which contains two components, text_1 and
   text_2.  These are defined in the slots for the Type.  For each
   component, there is a list of the compound element's actions, and
   next to each action, a drop-down list of the component's actions.
   This enables me to create text components which can't be edited, or
   other ones which turn into flashing blue gifs when I'm editing the
   template.  (Like I said, hard to think of useful examples).

   Anyway, my question here is: what might the best way to implement
   this event propagation be?  Since my compound elements are
   ObjectManagers, I can use their beforeTraverse hooks to sniff out
   the actions being called on them, and then inform each contained
   component in turn.  However, I find this really ugly.  

   Are there any better ways of doing this?  Or is this unecessary
   anyway?

Hope that made sense.  I'm hoping to refactor my work over the next
two weeks, so feedback before then would be great.  Otherwise, a
CMF1.2 in the next 2 weeks which implements someone else's vision of
this would be a very nice alternative :)

seb