So a few months ago, I started working on a little
compound document system for Zope. Sortof. It was being built as an internal framework of sorts, and I noticed some interesting CMF parallels, such as separation of
core concepts from
default implementations. The Core of this system,
SCS has a lot of usable default implementations, especially of Parts -- a document is basically made up of parts, or more precisely, a root part that contains other parts.
One of the reasons I started developing this was because of the paying project I'm currently working on. In pre-bid discussions with the customer, I realized that a more flexible compound object framework was going to be needed, and that it could potentially benefit our company in other ways as well. When we hit a lull in customers paying for my work (before I went independent), I started work on the compound system, partially as a way to cut time and costs later if we got this gig.
So, we have it. And today was the first day I finally got to try out some of the concepts. What I started on late this afternoon was a Journal. Knowing that I had the SCS, all I needed was a slight specialization of the default
SCS Document that would also be
CMF Content. This document class,
Journal, would consist of its default SCS Root part, which would consist only of Journal Entries. A
Journal Entry is a subclass of the default SCS
TextPart, basically with an extra
created timestamp. The Journal class has a method,
listEntries(), which in turn just asks its root part for all
journal/* type parts, sorts them by creation date, and reverses the sort.
This is done in relatively few lines of code. Partially because the SCS Container's default
listParts() implementation is rather powerful - it's a very hopped up replacement for the more traditional Zope container
objectValues() method. One can pass in an IFilter object, or a function, or some keyword values, with which to query the sub-parts of a container. This could, for example, allow usage of other Part types within a Journal to hold other information without getting in the way of entries themselves.
This is different than a folder full of entries. The paradigm is different. The paradigm of folder is just that of "something which can contain anything", but the folder itself is no real special object (it
can be in Zope, but few people take advantage of that fact). SCS, on the other hand, places extreme significance on the Document, the outermost object. A document contains one container (currently), and defers all sub-content related specific stuff on to it. This allows a document class to deal with other issues, such as meta data, or interfacing with a particular indexing scheme, while letting the Parts system basically take care of itself. The document is also allowed to dictate some degree of policy, like how a part or handler registry gets looked up, without (theoretically) placing TOO much burden on surrounding objects and systems.
So far, it's working. Tomorrow, I should be able to get things to a point where I can see how well this whole Journal-as-compound-document thing works out. Hopefully, it executes as cleanly as the code currently looks.