Re: [Dev] Content item initialization

[Donn Denman]

Yes, this is not ideal, but I couldn't figure out a better way to do 
it.  Maybe Phillip can figure out a better way in the near term.  
Indeed the situation is complicated both by stamping, and the "computed 
initial values" issue John mentions below.  When stamping, you are 
adding a superclass, but the __init__ for that superclass isn't called, 
since we're just morphing an item from one class/kind to another  (his 
action objects should be able to just __init__).  The repository does 
handle initialValues on those attributes, so that's the best method, if 
it works for you. The initMixin method provides a way to declare and 
call initialization for the mixin Kind, which is usually what you want 
for the computed initial values.

The basic rules are:
1) Use initialValue if you can (value need not be computed at runtime)
2) Use initMixin if the value is associated  with your superKind in 
general (every item using your superKind)
3) In rare cases your initialization will need to be in the classes 
__init__.  This happens if the initial value is associated with the 
specific class, not the general superKind.  E.g. a CalendarEvent (but 
everything that has Event-ness) needs some specific setup.

It's also possible that the test suite, which is old, has not been 
completely updated to follow the newer initialization conventions.

I hope this helps.
- Donn
On Jan 24, 2005, at 11:52 AM, 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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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