[Zope-CMF] Compound elements status

[Thomas Olsen]

Hi

On Monday 18 March 2002 12:57, seb bacon wrote:
> This should be in CMFDefault, not CMFCore, no?

I dont really have an opinion on that :-)

> I think this topic could do with more discussion before anything gets
> folded into the CMF.

Absolutely

> The CMFArticle is a specific application of a composite-type idea, viz.
> the user can add elements to a folder which aggregates them all together
> for display in a single page.

True

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

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

> CMFArticle is v. nice, but IMO is not a Composite document as stated
> elsewhere, rather it is something along the lines suggested by its name,
> a kind of 'newspaper page' type.  We could look at (a) extending it to
> meet those requirements, (b) we could decide the requirements were not
> correct, or (c) we could keep it as it is and develop a separate
> composite type.

I think I'd go for a combination of (a) and (b) :-) But I agree that we 
should get some more opinions before merging it in whatever module we decide 
to choose...

> seb

-- 
Regards,
    Thomas Olsen

http://www.tarpit.dk