[Zope-CMF] CMF Thoughts & Ideas (long!)

[seb bacon]

> > ...
> > a) Simplified the layout - took out all the divs and
> > used plain tables (i
> > found I was sometimes getting weird overlaps)
> 
> Ditto. On the plus side you can easily make every page
> look exactly how you want it. On the minus side you
> loose the ability of using other people's skins. In my
> case, worth the trouble.
>  

I can't think of a reason why new layouts should necessarily make your
skins incompatible with other people's.  OTOH, I imagine that as different
skins become available, they will be suitable for different needs,
rather than all replicating exactly the same functionality with
different stylesheets, etc.  It would be great if anyone with new
skins could post them in the dogbowl so others can try them.  Both the
ones mentioned so far sound really interesting, I'd love to have a
play with them. Talking of which, what happened to that skins
competition? Has the deadline been extended, I wonder ;-)   

< snip >
> > I have found 4 problems with this structure (which I
> > think are also relevant
> > to the earlier CompositeContent discussion thread on
> > this list)...
> > 
> > - Do you just link to the original content-object,
> > wherever it lives in the
> > site (e.g. using getitem to pull it from the
> > Member's folder into your
> > page), or do you make a copy of it? 

In my architecture, a CompositeContent object consists of a
CompositeContainer which contains one or CompositeComponents.

I think a CompositeContent object should be treated as an atomic
unit.  The components of which it comprises are really properties of
that object rather than first-class Portal components.  They should be
created inside the CompositeContainer when the container is generated.

Following this idea further, the container proxys all CMF functions on
behalf of the components.  When a component is edited, the workflow
state of the container is changed.  When a container's state is
altered, its workflow is responsible for updating permissionMappings,
etc, on its components.  For the catalog, the container returns its
components' text, and the components themselves do not participate at
all. 

> > - You don't have fine-grained control over your
> > layout. You can only apply
> > general rules in your Layout object (such as "All
> > images should be
> > left-aligned", "All document titles should be blue
> > and bold"), you can't
> > customise the appearance of each content-object.
> 
> Yes, but the opposite can become too dificult for the
> authors. You'd have to create a structure like
> folder-document-page-paragraph with the overhead of
> heavy logic and interface for each. I don't see how to
> accomplish such task in one page without lots of
> dhtml/javascript/whatyouhavenot.

It completely depends on your application, but I think it's important
to draw a distinction between content authors and template developers.
An author should not, IMO, have control over the layout of a page.
That's what the developers and designers are paid to do, and is how a
consistent look and feel can be applied across a whole site.  Instead,
an author should be able to chose from a series of template layouts,
and fill in the content.

For the template developer, my solution to customising the appearance
of each component is to provide a mapping between the Container
methods and the methods of its Components.  For example, whenever the
'edit' method of a container is called, an Image Component might have
its 'edit' method called too, whereas a Document Component might have
its 'view' method called.   

I've implemented Container and Component base classes, but I've not
bundled them up into something usable by anyone else, yet.  However,
the method mapping works, and they participate in workflows and
searches correctly.  I expect to have them in some kind of a readable
state by the end of the week, so if anyone wants a pop at them, let me
know. 

seb