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

[Jon Edwards]

Thanks for the feedback!

-----Original Message-----
From: seb bacon [mailto:seb@jamkit.com]
Sent: 24 April 2001 11:14

I can't think of a reason why new layouts should necessarily make your
skins incompatible with other people's.

Jon>> I don't think I explained it very well! There's an extra element in
there - "Layouts" - which isnt in the standard CMF way of doing things.
Well, actually, there's a few, I didnt go into full detail! :-) Apologies if
this explanation sounds oversimplified/patronising, I'm writing my
documentation live online here! ;-)

When you go to a "page" (i.e. when you click on the URL of a folder) it
finds the index_html in skins/custom. standard_html_header looks at the
"stylesheet_choice" property of the folder to know which stylesheet to call
(rather than the hard-coded call in the original code).

N.B. I'm thinking of somehow inserting SearchableText into the standard HTML
header metadata fields, to help with search-engine optimisation, has anyone
tried this?

index_html checks to see if you're logged-in, and shows you the Actions Bar
(formerly known as the Actions Box) at the top of the page if you are. It
then has a dtml-var which looks at the "layout_choice" property of the
folder to insert the appropriate layout. A layout is an empty HTML table
layout, with a dtml-var in each cell to call the cell's contents. At the
moment, the property for each cell's content (e.g. standard_top_bar in the
header-cell) is stored in the Layout's properties, but I might need to
abstract that out so that layouts can be reused with diff contents and on
diff sites! yikes!

A cell's content could be a simple DTML method (such as standard_top_bar,
news_box, or site_menu), or it could be a "Section" - my term for a
CompositeContentContainer! Hence my interest in the development of
CompositeContainers. <<Jon

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.

Jon>> Can't do that at the moment I'm afraid, as there's
"commercially-sensitive" info in there, but hopefully the above explains it
better? :-) <<Jon

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.

Jon>> As you said elsewhere, this depends on your application. A little
background - we're developing a CMS tailored to a specific market-sector,
consisting of medium-sized organisations, spread geographically (i.e a Head
Office and many small Branch Offices). Each Head Office will be a portal
instance, with the Branch Office sites "branching" off! :-) Each Branch
Office will probably want its own layout and colour-scheme (and possibly its
own domain name), but a lot of content will be common to many sites - hence
the need to re-use content-objects, but change their display
characteristics!

Don't ask about cataloguing/searching, I havent worked that out yet! It
would be great if you could constrain a search to a certain "branch" of the
site-tree, any ideas anyone? :-)

I'm currently foreseeing the following user-roles -

1. Site Manager - the person who assigns permissions, sets up layouts,
stylesheets, etc (probably working with a designer), administers the whole
thing.

2. Editors - responsible for one or more pages/sub-sites. They control the
layout and colour-scheme (within overall site-guidelines), write some of the
content, and select other content created by Contributors. It would be their
job to manage the CompositeContent objects for their page.

3. Contributors - people who create documents, pictures, news articles, and
upload them to their Member folder or to a "Group" folder (an area where
several Members can collaborate on the contents of a page, under the
moderation of that page's Editor).

4. Members - employees of the organisation and invited customers who become
members in order to be able to join discussions (anyone can view
discussions, only members can contribute) and receive mailings/newsletters.

So, under that structure, content-objects would be created independently, in
diff formats (an online submission, a Word doc, an Excel spreadsheet) and
might be re-used in several places in different forms. <<Jon

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.

Jon>> I dont think the workflow bit of this idea would work for me, but the
cataloguing bit might. What happens when a component is being edited? Does
the container become inaccessible through the website, or do you use some
sort of caching to keep the old version available until the new one is
posted? <<Jon

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.

Jon>> How do you deal with the issue of a Component being re-used in diff
containers? Or is this not relevant in your situation? <<Jon

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.

Jon>> I'd love to have a play with them, if you dont mind sharing your
ideas?

Cheers, Jon