[Dev] Custom parcel classes and Schema API integration

Phillip J. Eby pje at telecommunity.com
Thu May 19 09:52:28 PDT 2005


I'm about to check in the Schema API integration with the parcel loader.  I 
checked it in once before today, but ran into an issue with custom Parcel 
subclasses.  The Schema API supports using these subclasses, but I didn't 
realize that the integration makes it mandatory that you register these 
custom parcel classes with the Schema API.

The changes are very simple, and I've already taken care of them for these 
parcel subclasses:

* osaf.contentmodel.ContentModel.ContentModel
* osaf.contentmodel.mail.Mail.MailParcel
* osaf.framework.webserver.Web.WebParcel
* osaf.framework.webserver.servlets.inbound.Inbound.InboundParcel

In each case, I went to each directory whose parcel.xml uses the custom 
parcel class, and added a line like this to the __init__.py in that directory:

     from Inbound import InboundParcel as __parcel_class__

This tells the schema API that the parcel corresponding to that directory 
should use the specified class when creating the parcel Item.

Note that this means that using the 'itemClass' attribute to set a parcel's 
class is no longer useful; all parcels under the 
'http://osafoundation.org/parcels' namespace are now created by the Schema 
API, rather than by the parcel loader.  Thus, the 'itemClass' attribute on 
'Parcel' elements in the 'parcel.xml' file for OSAF parcels is effectively 
null and void.  Please use the __parcel_class__ mechanism if you add any 
new custom Parcel classes, or your custom class will not be used.

It would probably also make sense to remove the existing 'itemClass' 
attributes from the corresponding parcel.xml files, but I've elected not to 
do this yet, during this relatively early phase of the transition.

By the way, I found one Parcel subclass which does not appear to be used by 
any parcel.xml: the 'osaf.current.Current.Current' class subclasses Parcel, 
but is not referenced in a parcel 'itemClass', so far as I can tell.  It's 
not clear to me that it even needs to be a Parcel subclass, since it offers 
only classmethods that don't use any features of the Parcel base class.




More information about the Dev mailing list