[Chandler-dev] Moving color/etc out of ContentCollection

[Morgen Sagen]

On Mar 22, 2006, at 10:15 AM, 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!)
>
> Thoughts?
>
> Alec

Actually, I recently moved those *out* of osaf.app because I want  
other applications to be able to make use of 'all',  'trash', etc.  
without relying on osaf.app. I personally consider those to be part  
of the framework, and reusable by non-Chandler apps.  This was  
discussed on the mailing list:

    http://lists.osafoundation.org/pipermail/chandler-dev/2006- 
February/005060.html

...and my changes are cataloged here:

    http://wiki.osafoundation.org/bin/view/Journal/FrameworkModularity

If you feel they don't belong in osaf.pim, then perhaps we can come  
up with another parcel to place them in, but I would vote against  
osaf.app, since my assumption is that a non-Chandler application  
would not make use of osaf.app, as that is where things like the  
'Welcome Event' live.

~morgen