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

[Jon Edwards]

Hi all! First of all huge thanks to Digital Creations and the Zope/CMF
community for creating such an excellent set of tools and such a friendly
and helpful community!

I've been using Zope for about 2 months and CMF for about a month. I've been
in "stealth mode", as I've been leaving a company to set up a new one, but
now I can finally "decloak" and try to contribute something back to the
community! :-)

I'm still at the DTML level of the learning curve, but hopefully some of my
thoughts will help other newbies, and perhaps those with more Zen may point
out how I can improve!

1. Firstly, a resource for anyone interested in Content Management issues
generally - http://www.camworld.com/cms/ - the CMS-list at Camworld, has
some very interesting discussions about CMS issues. For example, in the
April archives - http://cms.filsa.net/archives/cms-list/2001/Apr/ - check
out the WfXML, SingleSource Conference, and Link Management threads, amongst
others.

2. CMF overview - it seems to me that, as well as being a great set of tools
in its own right, one of the main benefits of the CMF is that it overcomes
one of the "problems" of Zope! Before everyone flames me, let me say Zope is
a brilliant system with some excellent products, but if, like me, you are
not (yet!) a programmer, it is very difficult to integrate two or more of
those products into your implementation (and get them to "talk to each
other").

However, if all CMF-Products integrate with the Workflow, Membership,
Cataloguing, etc. APIs and structures, it will become much more of a
"plug-and-play", modular system, and thus have a wider appeal in the market.
For example, you could make every member's MyStuff page a Swishdot, and
easily incorporate PortalPolls, Links and external RSS newsfeeds into the
side-boxes - hey-presto, instant Weblogs system, completely searchable, and
can be managed through Workflow! I wonder whether this should be emphasised
more in the docs, How-Tos, etc as a major "selling-point"?

3. "Wot I Have Dun!" - a few things I found useful. I'll keep em brief, if
people want more detail, please ask.

a) Simplified the layout - took out all the divs and used plain tables (i
found I was sometimes getting weird overlaps)

b) Actions box - our sites will have many anonymous visitors, and only a
handful of editors/contibutors, so I made the Actions Box a flat bar at the
top of the page, which is only visible when you are logged in (editors
bookmark the login screen so they can find it easily). This gives you more
room on your screen, and is less confusing to casual visitors.

c) Edit screens - created a separate editpage_header with its own stylesheet
(lightgrey backgrounds, black text, so it looks more like an app) - our
editors found this made a clearer differentiation between editing stuff and
viewing the results.

d) WYSIWYG editor - used a Javascript WYSIWYG html editor for all textarea
bits on the edit forms (our editors know little HTML and didnt want to learn
Structured Text). I used this one - http://dhtml.yaourts.com/ - which is
IE4+ only, but I think there are others compatible with Netscape. This
includes dropdown boxes for styles and colours - in the future I'm hoping to
link these to the stylesheets, so contributors can only pick styles and
colours that match the overall look of the site.

e) Site Structure - errr... this is kinda complex! :-) I've hacked together
a "CompositeContent" sorta structure, but using only DTML. Each "page" is a
Portal Folder, with added properties.

(N.B it would great if you could add properties to Portal Documents, Images,
NewsItems, etc, through the ZMI, as you can currently with Portal Folders.
You can store your butchered objects in a folder in Skins, then just use the
manage-addClone/manage_editProperties method to create new ones -
quick-and-dirty way to create products for non-programmers! Alternatively,
perhaps in the future you could do this through portal_types? ...create a
new type, based on an existing one -which you can already do- and then add a
few extra properties and give it a suitable meta-type name?)

The page properties tell it which stylesheet to use (so you can have diff
colour schemes in diff parts of the site), which Layout to use (a layout is
a "skeleton" page with empty cells where you can slot in content - you can
have several different layouts per site), and which actual content-objects
go in which cell (currently a "lines" property for each cell, so you can
have several docs, images, and determine their order). Editors have a simple
EditPage form with dropdown boxes to select Layout, stylesheet, content.

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? If you just link to it, what happens if
the original author changes it? Those changes will immediately show on your
"page" without you getting a chance to review them! On the other hand, if
you make a copy, you can hack it to suit your context, but any changes the
original author makes won't be available, and you're duplicating all your
content!

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

- It can get slow if you have a big page with lots of content-objects! (This
is obviously not helped by the fact it's all written in DTML at the moment!)

- How do you search? (This was mentioned in the CompositeContent discussion)
You want a search to find only the content-objects which have been
"published" to a page, and when you click on the result, you want it to show
the whole page, not the content-object on its own!

I have the beginnings of a theory to solve this, but would welcome input
from others...

i) Create a "Content-Metadata" object - an object that links a
content-object (such as an Image or Document) to its slot on a page, and
says how and when it is displayed. I was thinking of adding properties to a
DTML Document to prototype this. So for example, when an editor is composing
their page, they select a Portal Document to be included - this creates a
"content-metadata" object (and adds its name to the lines property for that
section of the page). The editor is then given a form where they can select
whether the object is just a link to the original, or a copy of it (in which
case the copy is stored in the content-metadata object perhaps?), what
display properties to use (header colour, alignment, that sort of thing),
and things like expiry-date (for this page only, not the whole site). When
reviewing a page, any items which have been updated by the original author
could easily be highlighted (by comparing modified dates), so the editor
could go view them and see if they want to update their copy.

ii) Create a "build" method for pages - every pagefolder has an index_html
method which is like a "compiled" version of the page. Whenever one of the
page's components is updated, the "build" method is autorun, scanning
through all the components, just like a "view" method, but writing the
resulting html to the index-html. Some bits that change often - like
news_box - might be left as DTML inside index_html, to be calculated "on the
fly". This should speed up display to the end-user, and means that your
catalog (for end-user searches at least) only needs to index all the
index_html pages.

Anyway, enough of my ramblings! I have lots more ideas if people found these
useful, but don't want to bore you all if you've already thought of them!
:-)

Apologies for the length of this message - two months of pent-up ideas
spilling out!

Cheers, Jon