[Dev] ContentModel, Calendar, Contacts, etc. reorganization/flattening

[Ted Leung]

On Jul 28, 2005, at 10:36 AM, Alec Flett wrote:

> Phillip J. Eby wrote:
>
>> One of the 0.6 developer platform goals is to flatten our Python  
>> package hierarchy a bit,
>>
>>
>
> This is really great - I've been looking forward to this kind of  
> change for a while. The only thing I see that I'd like changed  
> slightly from your list is this:
>
>> osaf.contentmodel.calendar.Calendar.*   -> osaf.pim.calendar.*
>> osaf.contentmodel.calendar.Recurrence.* -> osaf.pim.recurrence.*
>>
> Recurrence is really part of the Calendar and the filename split is  
> really just to break apart the logic within the module. Ideally  
> we'd have osaf.pim.calendar.CalendarEventMixin,  
> osaf.pim.calendar.RecurrenceRuleSet, and so forth. Is there an  
> obvious convention in python (like import * from... inside of  
> __init__.py) to allow this to happen while still letting  
> Calendar.py and Recurrence.py remain seperate files within the  
> osaf.pim.calendar module?
>
> On a related note, why osaf.pim? why not just "chandler"? I'm  
> guessing the argument is that you could reuse these objects outside  
> of chandler, which seems nice.. though even the osaf prefix seems  
> superfluous to me..

I'd be in favor of just plain 'pim'

>
> So on a related note, I'd like to propose some future renames after  
> you're done with this one
> (and maybe you've already thought about this)
>
> osaf.views.main -> chandler (in this case, this really is the  
> chandler product)
> osaf.framework.blocks -> cpia or cpia.blocks (break cpia out from  
> being a chandler-only thing)
> osaf.framework.attributeEditors -> cpia.attributeEditors (or  
> cpia.attributeeditors?)
> osaf.framework.twisted -> chandler.twisted
> osaf.framework.scripting -> cpia.script
> osaf.app -> chandler

When we get to these, we should also look at reorganizing some of the  
files in the modules.  Today I tried to convert  the parcel.xml for  
Flickr to using Python.  In order to do that, I had to import a bunch  
of classes so that I could use the new update method.

One of the imports was

from osaf.framework.blocks.DynamicContainerBlocks import MenuItem

DynamicContainerBlocks might mean something from the point of view of  
the implementation, but from the point of view of somebody just  
trying to write a parcel, its non-intuitive.

Ted