[Chandler-dev] Getting rid of all __init__ methods (for Item subclasses)

[Grant Baillie]

On 22 Mar, 2007, at 11:58, Bryan Stearns wrote:

> Phillip J. Eby wrote:
>> In discussion with Morgen, Bear, and John, we've determined that  
>> the optimum way to support fast dump and reload with proper  
>> support for multiple inheritance and type changes due to sharing,  
>> is to get rid of custom __init__ methods for Item subclasses.
>> [...]
>> The second feature is a new 'schema.initialValues()' function that  
>> you can call in the body of a class to define how the class'  
>> attributes should be initialized.  For example:
>>
>>     class ContentItem(Item):
>>         ...
>>         schema.initialValues(
>>             createdOn = lambda self: datetime.now()
>>         )
>>
>> In other words, keyword arguments are used for the attribute  
>> names, and the values are functions taking the item as an argument  
>> and returning the desired attribute value.  The attributes are  
>> *not* limited to schema attributes; they can be transient  
>> attributes or even properties, and they override any values  
>> defined in a superclass or in the attribute's "initialValue"  
>> aspect.  This also eliminates the need for __init__ to supply  
>> default values for keyword arguments or to change default  
>> attribute values established by base classes.
>>
>> The order that individual attributes will be set in is not  
>> guaranteeed, but they are *all* set before your __setup__ method  
>> is called.  Any keyword arguments passed to __init__ will prevent  
>> that attribute value from being calculated - it'll just be set  
>> from the keyword before __setup__ is called.
> Can you please wrap this initialization with:
>        with view.observersDeferred():
>            with view.reindexingDeferred():
>                # change item class here
>                # do initialization here
>
> so that observers don't fire until the state of the object is  
> consistent? (I don't know whether disabling indexing is important,  
> but I don't think it'll hurt...)

I think, but am not 100% sure, the reindexingDeferred() is dangerous,  
since setting attributes (in general) can cause reindexing of  
FilterCollections that depend on those attributes.

--Grant