[Zope-dev] initializing objects in ZPatterns

[Christian Scholz]

Hi!

> > I just encountered another problem with ZPatterns (well not exactly with ZPatterns
> > but the way I use it.. ;-)
> > 
> > I have some Specialist with a normal rack which stores data persistently in the ZODB.
> > Everytime I am creating a new object I want to create an object of another specialist
> > on the fly and store it's id inside my first object.
> > 
> > Thus I have setup a SkinScript with the following content:
> > 
> > 
> >   INITIALIZE OBJECT WITH company_address=addresses.createAddress()
> > 
> >   WITH addresses.getItem(self.company_address) COMPUTE company_addr=RESULT
> > 
> >   STORE company_address IN SELF
> > 
> > The createAddress is called actually and it returns the ID of the new object
> > (thus the object is created). Unfortunately the id is not stored inside
> > company_address. After reading the new object again this value is still empty
> > (and thus also no address object is return by the address specialist). Same happens
> > when just using some dummy property and filling it with a fixed string. This
> > also disappears..
> 
> To get company_address stored, you can probably do something like:
> 
>   your_object.manage_changeProperties(company_address=your_object.company_address)
> 
> or possibly your_object.propertysheets.NameOfSheet.manage_changeProperties...
> depending on what kind of object you're using.
> 
> You could have this as a trigger:
> 
> WHEN OBJECT ADDED CALL
>   self.manage_changeProperties(company_address=self.company_address)

Well, the first one seems to work, but the SkinScript trigger does not unfortunately.
So I will try to incorporate this into my other code (which is a bit more tricky
as I automated all the property handling stuff). But thanks anyway!

> As for whether it is a bug, the implementation of the INITALIZE clause just puts
> its attributes directly into the DataSkin's attribute-cache. It appears to be
> designed for the behaviour that you see.
> 
> You could get the behaviour that you want by making the implementation actually
> set the attributes instead. I'm not sure what the other implications of doing
> that are, though.
> 
> If you're interested, the code is in
> 
>   lib/python/Products/ZPatterns/SkinScript/Components.py
> about line 71.

ok, thanks, will have a look at that.

cheers,
  Christian