[Zope-CMF] Compound elements status

[seb bacon]

Thomas Olsen wrote:
>>This should be in CMFDefault, not CMFCore, no?
> I dont really have an opinion on that :-)
>>The original proposal was all about 'slots': a Type which knows which
>>elements it is composed of.
> 
> 
> I never really grasped how these slots should be used. Can anyone elaborate 
> on that? My goal with CMFArticle was to create a 'Container Document' where 
> you could add new element types as kind of plugins without having to change 
> the implementation of the document. Instead the elements implements an 
> interface allowing the document to query each element how it should be 
> presented. I'm actually in the process of making a 'StreamingMediaElement' to 
> use with MyMediaManager :-)
> 
> This gives the greatest flexibily as I see it. At the same time it should be 
> possible (as mentioned in an earlier post by Philippe) to create site 
> specific templates with fixed number of specific elements but I see this as 
> site customization, not something to be implemented in the document type.

Here's my motivation for having 'slots'.

When you display a page with its 'view' action, you want to display each 
of its components according to their 'view' action.  How about if you 
have a 'view comments' action for a page, which puts some copy at the 
top regarding comment threads, and then displays each component with its 
thread beneath.  Then you need a way to map between the container's 
action and those of its components.  This can only be done in a 'slot' 
type definition.

Also, if you have slots with named components, you get to define the 
layout of the page accurately ('image_1 goes here, text_3 goes there'), 
which it is hard to do when the components are looped over in a repeat 
clause.  Of course you could extend the interface with CMFArticle to 
allow you to name elements; however, the user would then need access to 
the page layout source too.

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?

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.

>>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 haven't tested it very much but CMFArticle should work like that except for 
> subarticles which appears like chapters and are catalogued separately.

Yes, my bad.
I'm **really** snowed under with work at the moment so I haven't time to do
any releasing of my code for you to look at yet.  Sorry!  Hopefully my
thoughts are useful in the meantime.

seb