[Chandler-dev] Moving color/etc out of ContentCollection
alecf at osafoundation.org
Thu Mar 23 14:11:40 PST 2006
I just checked in changes that pull the following attributes out of
and got rid of the setup() method for ContentCollection. Note that I did
not get rid of InclusionExclusionCollection's setup() method.. we can
fix that in another step.
I took pje's suggestion and I moved it into an annotation in
osaf.usercollections called UserCollection.
'setup()' became 'ensureColor()' and is only called by consumers who
care about color, such as the sidebar and calendar (instead of
distributing this requirement on anyone who makes a collection)
Everything else stayed just where it was before. There's a slight
reduction in dependencies as a result. Whee!
Alec Flett wrote:
> I'm in the process of (finally) moving color, outOfTheBoxCollection,
> etc out of 'ContentCollection' and into an Annotation called
> 'UserCollection' The basic idea is that if a collection does need to
> be user-facing, and thus have things like color, etc., then we can use
> this annotation to attach those attributes.
> I'm putting this annotation in osaf.app, so that all consumers of
> these attributes now must import UserCollection from osaf.app..
> Whereas before they would say:
> foo.color = blah
> now they say
> from osaf.app import UserCollection
> UserCollection(foo).color = blah
> I personally like the explicit-ness of this, so consumers understand
> that they are expecting the collection to be a user collection.
> As a side effect of this, I'm finding that I can keep dependencies to
> a minimum by moving in/out/all/trash to osaf.app. This seems like the
> right thing to do anyway because it seems like these chandler-specific
> collections belong at a higher level than osaf.pim.
> I don't see this being a problem other than making changes across the
> whole codebase, but I'm doing that right now. Does anyone have any
> issues with this change? I'm feeling pretty positive that I can move
> these from osaf.pim into osaf.app without creating a dependency from
> osaf.pim to osaf.app (that dependency would defeat the purpose of this
> whole exercise!)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev