application dialogs parcels/osaf app scripts webhome jsolait lib examples framework attributeEditors blocks calendar certstore scripting twisted mail pim calendar servlets sharing views blockviewer content demo detail main repositoryviewer util repository item packs chandler schema model clouds items persistence schema util ../internal/chandlerdb/chandlerdb item persistence schema util

Reid's Notes on the Architecture of Chandler

I am modifying how the buttons in the Markup Bar behave and thus am directly modifying Python code in Chandler for the first time. These notes are to help me make a mental mapping between (at first) the simple layout of the filesystem of Python code and its functionality.

To the right is a list of the directories (as of Wed Sep 13 2006) holding "useful" Python code in Chandler, relative to the directory chandler/chandler in an svn checkout of the code.

At the top level we have application, parcels, and repository. In a separate directory, we have chandlerdb.

application

"application" has a small number of small classes that are used extensively in "parcels". The file application/schema.py file is very important. Everything seems to define its type by referencing one of the types defined in that file. More information can be found in the file application/parcel-schema-guide.txt

schema

A lot of files in Chandler are parcels. At least, they have a file-level function called installParcel(parcel, oldVersion=None). This function calls class methods from within the same file named class.register(parcel, xxx, name), where xxx is a dictionary, or class.update(parcel, "schemaPathElement").

The class.update method seems to attach schemaPathElement to the namespace of the parcel. So if you are looking at, e.g., parcels/osaf/framework/attributeEditors, then the installParcel() function contains a call to AttributeEditorMappingCollection.update(parcel, "aeMappings").

This allows code elsewhere, e.g. in AttributeEditorMapping.__init__() to say things like aeMappings = schema.ns("osaf.framework.attributeEditors", self.itsView).aeMappings -- note the "aeMappings" attribute at the end there. It was accessible because of the update() call above.

In this way, a simplified, somewhat degenerate namespace exists parallelling that of the filesystem. For if just the filesystem determined the namespace mapping, it might be schema.ns("osaf.framework.attributeEditors.AttributeEditors", self.itsView).AttributeEditorMappingCollection or some such.

parcels/osaf

Chandler's main Python code lives under "parcels/osaf". It's as if Chandler is one big plug-in to itself.

framework/attributeEditors

I recently did some work on the detail view and learned a thing or two about attribute editors.

• attribute editors may be used in situations where a CPIA block is not available/involved
• attribute editors are keyed off of the type they are editing, by way of a couple of big lookup tables

chandlerdb

This deals with the database layer of chandler, where items and schema are mapped to a Berkeley DB database.