[Zope-CMF] Compound documents

[Thomas Olsen]

On Tuesday 19 March 2002 01:05, Jeffrey P Shell wrote:
> So, I see needs for both the templated system, with the ability to rigidly
> define slot requirements and an accurate layout; and for a more free-form
> system with a less accurate layout that is better suited for longer
> documents that need to embed different content along the way (like teaching
> lessons, white papers with diagrams and tables, etc) that a rigid template
> can't catch.

I'm beginng to lean towards this opinion too. I find the idea of having Types 
behave like parts when presented in a template *very* exciting and I can hear 
that a lot of people have interesting ideas about it. I also hope that some 
of these ideas will evolve not only to a compound or composit document type 
as described in Jeffreys proposal but also to a future implementation of how 
to glue objects (Types) together in the CMF.

CMFArticle is not at all a usable foundation to build such an implementation 
on. I made the product to have a simple way of creating free form articles 
(or whatever one wants to call a web page) containing different elements 
(simple text, html, images, tables) and doing this in a way that would make 
it easy for a web programmer to extend the product with new element types.

As I have a feeling that most people in this thread commenting about 
functionality and product design haven't seen the product in action, I think 
we could save some time if I describe the implementation and functionality in 
a nice mixture here. Then people can decide whether they find it useable or 
not :-)

Article is the Portal Type class. It has five actions: View, Edit, Metadata, 
Elements and Sub articles. Edit and Metadata are similar to standard forms on 
other CMF Types. 
Elements displays a form with all the elements in the current article. They 
can be sorted, edited and deleted and you can open a popup for editing 
additional properties like floating, clearing other elements, scaling images 
etc. Furthermore you can add new elements from a list of registered element 
types.
Subarticles displays a list of subarticles which are articles contained in 
articles. They can be sorted or deleted or you can select a subarticle to 
edit that instead.
The View action displays the rendered article. In the default skins it 
displays the title as a header, the description as a lead-in in italic. If 
there are any subarticles they will then be listed as chapters followed by 
the different elements in the current article. At the bottom of the page 
there are next/previous/up links for navigation between parent/sub articles.

The Article class inherits from PortalFolder, PortalContent and 
DefaultDublinCoreImpl. It acts mostly as a placeholder for the elements.

All elements inherits from at least AbstractElement which itself inherits 
from Persistent, Item and Aquisition.Implicit and they are not Portal Types. 
This is intentional as I wanted the article to act as a single entity in the 
portal not as a collection of elements.

To be available to the article each element class registers it self with the 
Article class. Each element also implements a set of methods defined in the 
Element interface class. These methods are:

 - getEditForm: returns the name of the skin to be used when assembling the 
Elements form.

 - getView: returns the name of the skin to be used when assembling the 
article view.

 - edit: this is called from the abstract class to set the element properties 
(I stile this from CMFTopic :-)

 - SearchableText: called by Article.SearchableText.

Optional methods are:

 - getEditExtraForm: returns the skin to be used when assembling the "More.." 
popup form.

 - editExtra: called from the abstract class for setting extra properties.


I hope this is useful :-) Sorry for the rather longish post.

-- 
Regards,
    Thomas Olsen

http://www.tarpit.dk