[Zope-CMF] Compound elements status

[Jeffrey P Shell]

On 3/18/02 4:15 PM, "seb bacon" <seb@jamkit.com> wrote:

> Thomas Olsen wrote:
>> 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.

I'm currently in the middle of designing my own compound element system
<grin>, and have been wrestling over templates and slots and how best to
deal with them.  I've decided that my foundation design (which is not tied
to the CMF, and the final components may not be either) is *not* going to
deal with them, although they would in many regards make my life easier, but
at the expense of the target audience for the bid we're hoping to get.

Basically, I'm focusing on shops where there is a need for relatively
free-form content entry, without the presence of a Template Designer (see
actor in reference [1]).  But I'm hoping to allow enough flexibility with
the primary framework to allow for situations where explicit designs can be
implemented and maintained by such an actor.

The basic design for how Parts (to borrow the OpenDoc term) are created [2]
should - in my system - allow flexibility for more advanced Part Containers
(which may be parts themselves) to use the sort of template structure shown
in figure [1] when querying for parts to instantiate from the registry.  I
should note that I haven't yet gotten to the design on how these things
should render themselves to allow similar flexibility.

I liked what I saw in CMFArticle screen shots - it looked similar to the
next generation of a simple compound document I've created and have been
using already (basically a class which mixes in a class that handles
uploading images and files, and a link management class, all used as a base
for a ZClass in which the editing forms and their target actions are
defined) that I've had in mind ever since a recent meeting with a
perspective client.  The client was impressed with the software that already
existed, but seemed a little dismayed over the fact that the images all
rendered in the same place (after the text content) except for a special
case header image.  Whereas the client for whom that software was designed
appreciated the pre-baked template.

So, I see needs for both the templated system, with the ability to rigidly
define slot requirements and an accurate layout; and for a more free-form
system with a less accurate layout that is better suited for longer
documents that need to embed different content along the way (like teaching
lessons, white papers with diagrams and tables, etc) that a rigid template
can't catch.

 [1] http://cmf.zope.org/rqmts/proposals/compounds/manageranddesigner.png
 [2] http://cmf.zope.org/Members/jshell/compound_interactions.jpg

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

> 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 don't follow what you're saying here.

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

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.

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

The same goes for me!  I'm lucky I could make time to get back in on this
discussion, which is something I've been championing for a while.

-- 
Jeffrey P Shell 
www.cuemedia.com