[Dev] Content item initialization

[John Anderson]

Often you need to create an item and modify it further depending upon 
how you intend to use it. For example. Making a new mail item then set 
the to field to whoever you're going to send it to for the particular 
situation. Usually __init__ does the base initialization, but if you 
need to change some other stuff, you're responsible for doing that in 
your code.

Using onItemLoad usually doesn't work because the value (e.g. the to 
field of the email) you're calculate usually needs to get persisted. If 
it didn't need to get persisted you could just calculate it every time 
you needed it and there wouldn't be any reason to make it an attribute. 
So I've yet to find a case where it makes sense to use onItemLoad.

John

Andi Vajda wrote:

>
> Couldn't this be done in the constructor for that item's class ?
> Or, if the value needs to be recomputed every time the item is loaded 
> from the repository, with an onItemLoad(self, view) method ?
>
> Andi..
>
> On Mon, 24 Jan 2005, John Anderson wrote:
>
>> Hi Bryan:
>>
>> I agree with your comments about _initMixin. I had hoped to make it 
>> go away and just use initial values. However, Donn pointed out that 
>> some of the values that needed for the initialization were not known 
>> at the time the initial value needs to be set by the parcel xml. For 
>> example, some of the values need to be computed at the time the item 
>> is created after Chandler has been running. In those cases it doesn't 
>> seem unreasonable to just have to set some values after creating the 
>> item -- but this should only be done if initialValue in the parcel 
>> xml won't work.
>>
>> John
>>
>> Bryan Stearns wrote:
>>
>>> I recently added a couple of (boolean) attributes to 
>>> CalendarEventMixin, and I'm confused about the way they're being 
>>> initialized:
>>>
>>> - None of the existing attributes have initialValues in the 
>>> content-model parcel.xml, though that seems to be to be the right 
>>> place to define them.
>>> - I saw other attributes being initialized in CalendarEventMixin's 
>>> _initMixin(), so I defined mine there; _initMixin() is called by 
>>> InitOutgoingAttributes(), which is called by MainView's 
>>> onNewEvent(), so this worked.
>>> - When I ran the unit tests, however, the calendar tests failed: 
>>> simply creating a CalendarEvent() (that is, just using its 
>>> constructor) doesn't call InitOutgoingAttributes(), so I had to 
>>> initialize my new attributes in the unit tests separately (just like 
>>> other attributes were being explicitly initialized in the unit 
>>> tests). This allowed the unit tests to succeed.
>>>
>>> It bothers me that I need to remember to initialize attributes in 
>>> two different places (especially since one place is solely to 
>>> support unit testing; this seems to make our unit tests less 
>>> rigorous). Shouldn't we use initialValues?
>>>
>>> ...Bryan
>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "Dev" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/dev
>>
>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>>