Christian Scholz wrote:
> 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:
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
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
about line 71.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -