[Zope-CMF] Zope component model and CMF

Chris Withers chrisw@nipltd.com
Fri, 06 Jul 2001 14:06:37 +0100


Shane Hathaway wrote:
> 
> http://dev.zope.org/Wikis/DevSite/Proposals/ApplyComponentModelToCMF

(positive hat)

Looks great on the whole :-)

> The metadata views are common to all standard CMF content, so presentation
> components will need a way to inherit from other presentation components.

Well, yes, but surely you should also be able to share presentation components
between different CMF Content types?
For example, Document, News Item and Reply might all have exactly the same
metadata, is there any reason why they couldn't use the same Metadata
presentation component?

Maybe presentation components could be acquired from some 'higher place' when
they need to be re-used like this?

> Going deeper, presentation components will need an inheritance hierarchy. One use case involves
> site managers who set up a new CMF site and want to customize the presentation of news items.
> The default presentation components will be filesystem directory views. The site manager will visit
> the news_item presentation component and click the customize button. This will create a new
> presentation component, usually in a different folder, that inherits from the default presentation
> component. Then the site manager will visit the new presentation component and click an
> override button to make a locally modifiable copy of a view.

This doesn't quite make sense to me. When I click 'customize' on a presentation
component, I want a new editable copy of the whole component to appear. I don't
want to have to do this and then customise to somewhere else first before I can
actually make changes to anything. 

Of course, from a maintenance poitn of view, you wouldn't actually want to copy
all the methods etc into 'customized' versions straight away 'cos then when the
FS-based version gets updated, they won't get the benefits, even if the end user
hasn't modified them at all.

So, how about: click customize of the FS-presentation object, this creates the
ZODB based version which doesn't actually contain anything, but appears to
contain editable versiosn of everything. The first time these editable versions
are saved, they are then actually stored in the ZODB?

Does that make sense? If not, I need to explain better :-)

> One
> way to deal with this is to perform reindexing in the presentation layer. Another is to make the
> catalog transparent, reindexing whenever objects are changed. This is not a vital issue for now.

Re-indexing in the presenation layer (as well as rebuilding the discussion tree
if necessary; see earlier list threads about my ideas for the discussion tool)
are things I'm having to do for Swishdot, this code is fine where it is, but if
it gets customized, it'll make life more difficult when it is transparently
done.

...of course, I think it's vital that transparent re-indexing (and other hooked
in operations, like discussions modification) happen. What service/tool/etc will
enable this to happen?

cheers,

Chris