[Zope-CMF] Re: Our CMF-CMS Demo

Seb Bacon seb@jamkit.com
Wed, 4 Jul 2001 10:28:18 +0100


* Jon Edwards <jon@pcgs.freeserve.co.uk> [010703 11:00]:
> I'm working on it! I thought Seb's suggestion that people building CMS
> functionality on top of CMF should define a few "standards" to improve
> interoperability was excellent, so I'm trying to produce something along
> those lines.
> 
> (Seb, 'scuse me if I paraphrased you clumsily, any chance you could post
> your initial thoughts/examples to get us started... just brief
> "back-of-a-cigarette-packet" notes? I think I understand what you mean, but
> I'm finding it hard to verbalise! :-)

That's pretty much what I meant, although I'd go further and say a
standard should the basis for a community implementation, too.  

I see a need for a community / DC standard for a CMF-based CMS,
which takes the best from all worlds.  It should follow the principles
DC has layed out for the CMF - a framework, not an application[1].
Then people can build on top of it however they want.  I haven't
looked closely at Kontentor or MetaPublisher yet, and should do. 

The main problems, I think, are:

 - Page composition.  
   How are pages composed?  There have been some discussions about
   CompositeContainers and the like elsewhere.  It would be nice if
   the vanilla CMF Types could be used as bits of pages - a text block
   here, an Image there.
   Structurally, I think pages should follow the Composite pattern [2]
   so that they can be recursively composed.  You should be able to
   create widgets, sets of widgets, images, groups of images, etc, and
   treat them all uniformly.  You'd have to mixin some extra
   funtionality to the components to acheive this, though.

 - Template (layout) editing.
   Should the user / site manager be able to create their own
   templates TTW, or is this a function of the Developer / Designer?
   If a user can add, for example, an image to a page layout, how is
   it added?  Should we borrow from the various flavours of layout
   managers available in GUI toolkits?  Or should we be hiding this
   complexity from the user? 

 - Navigational control
   We need a standard framework for creating navigations, so they can
   be 'dropped in' to any site.  A natural one is to use the Zope
   folder hierarchy, and build navigations by walking the tree(s).
   If we do this, we lose the ability to be location-neutral with
   content; on the other hand, we gain simplicity by reusing an
   existing metaphor.  There is a proposal about defining the
   relationships between documents, I think by Ken, which may be
   relevant here, but I can't access the proposals folder on the
   dogbowl to check.
   
Other (simpler) issues, some one which are not necessarily 
'framework' problems, are: 

  - UI (edit items in situ, or from a different location)
  - Other functions of navigation / site structure, like page
    ordering 
  - Fine-grained 'Template' security: it should be possible to
    restrict content type creation by role, TTW
  - Same goes for skins

Well, that'll do for starters :-)

seb

-- 

[1] See Shane's escape velocity metaphor:
  http://lists.zope.org/pipermail/zope-cmf/2001-May/007030.html

[2] I'm referring to the 'gang of four' pattern.  Note for uninitiated -
  Design Patterns, by Gamma et al:
  http://www.amazon.com/exec/obidos/ASIN/0201633612/