[Zope-CMF] Composite Content

[seb bacon]

On this topic, I'm finding a big stumbling block is something which is
probably quite simple: CMF Types only provide for rendering themselves
through methods, but if they are to be part of a CompositeContainer,
they must also know how to render themselves within a DTML Method.

Furthermore, CompositeComponents must render themselves in a manner
dependent upon the action performed on the CompositeContainer.  If the
container is being viewed with an Edit action, for example, its
components must know how to display themselves accordingly.

I guess the best way is to add an extra action mapping for Types in
the CompositeContainer properties, which maps an optional number of
its actions to those of each Component, e.g.

Container      Component1    Component2
view	       view	     view_foo
edit	       edit_foo	     edit_foo

If I'm onto a Good Thing, I'm OK with implementing the mappings, I
think, but I have no idea how to map actions to the way a component
renders itself as part of a template: do I have to override __call__,
or something?  Are there any pointers for this?

What does anyone else think?  I'm really tired and have to go home, so
that may not have made any sense ;)

seb

* Kent Polk <kent@tiamat.goathill.org> [010417 18:58]:
> >> Has there been any further discussion on the topic of Composite
> >> Content?
> > 
> > For my application, I need not only a CompositeContent Type, but also
> > special CompositeComponent Types too.  This is because Components
> > participate in a Portal only through the CompositeContent which they
> > compose. 
> > 
> > A CompositeContent must:
> > 
> >  - return a SearchableText which is made up of its components
> >  - have slots which are configurable TTW
> > 
> > CompositeComponents:
> > 
> >  - must participate in the workflow of their container, rather
> >    than their own
> 
> I think this applies, though in my app, different components need
> different workflows, based on the type of component. If the container
> knows enough to manage the workflow for the components, they are
> likely more easily managed.
> 
> >  - must participle in catalogs only through their containers  
> >  - have no need of extensive (i.e. DublinCore) metadata, since this,
> >    too, is a property of the container.
> 
> For much of my app, cataloging will primarily be for the metadata,
> and DublinCore doesn't quite cover the bases - will need additional
> metadata which needs to be Acquirable through the composite framework,
> which appears to agree with it being a property of the container.
> 
> (My components will also need additional attributes and methods in
> order to publish themselves...)
> 
> > Would these requirements apply more generally?  I think they
> > would.
>  
> I believe so.
> 
> > I've implemented a CompositeContent as a Folderish PortalContent
> > object, and I've implemented a Document-like CompositeComponent, and
> > it all works quite well in a prototype kind of way.  However, I've not
> > abstracted the functionality into a helper class which can be
> > implemented ad hoc TTW.
> 
> Mind if I try to implement some of my component types with it and
> provide some feedback?
> 
> Thanks