Re: [Zope-dev] ZPatterns AttributeProvider question
Hi!
Yes, as said above it registers for handlers and attributes. Also _objectChanged and _SetAttributeFor() etc. are called. They're just not called directly after creating the object (when being in the same request that is).
_objectChanged() is a transaction-commit message. You'll only get it when the (sub)transaction commits. You'll receive _objectChanging() just *before* the object changes.
Yep, that's how I understood it. That's also working.
As for _SetAttributeFor(), it should be called at the time manage_changeProperties executes, not at object creation. Are you sure that you have it properly named and that it isn't still being defined by one of your ancestor classes instead? The "AttributeProvider" and "GTMixin" base classes in ZPatterns implement _SetAttributeFor() by simply noting the change for later. If you don't override this behavior, your class won't see _SetAttributFor() itself.
Well, it actually is working, just not directly after creating the new object. So what I do now as workaround is dtml method 1: - creates new object via newItem() - redirects to dtml method 2 dtml method 2: - retrieves the newly created object with getItem() - calls manage_changeProperties on that object This is working. Putting the manage_changeProperties directly after the newItem() is not working. I've also tried retrieving the new object directly after newItem() and calling manage_changeProperties on that but this also did not work. (so it is named correctly as otherwise it wouldn't be called either in dtml method 2). So the main problem is: SetAttributeFor() is not called (and also _objectChanging() is not called) in the same request cycle after creating a new object. They're called however in the "next" request after retrieving it with getItem(). Maybe it helps if I publish the source somewhere? It's gonna be some public product anyway. regards, Christian -- COM.lounge http://comlounge.net/ communication & design info@comlounge.net
Christian Scholz wrote:
So what I do now as workaround is
dtml method 1:
- creates new object via newItem() - redirects to dtml method 2
dtml method 2: - retrieves the newly created object with getItem() - calls manage_changeProperties on that object
This is working. Putting the manage_changeProperties directly after the newItem() is not working. I've also tried retrieving the new object directly after newItem() and calling manage_changeProperties on that but this also did not work. (so it is named correctly as otherwise it wouldn't be called either in dtml method 2).
So the main problem is: SetAttributeFor() is not called (and also _objectChanging() is not called) in the same request cycle after creating a new object. They're called however in the "next" request after retrieving it with getItem().
As a simpler workaround, you can use your_object.commitSubtransaction() instead of redirecting to a new page. A few Zope versions ago, that could conceivably cause problems with certain database adapters. With some of the recent fixes to Zope, you should be ok using subtransactions even with DAs that don't support them. Check this out before you use it for important stuff though :-) You really should be able to create a new object and set its attributes in the same transaction. The status of the object (_v_status in DataSkin.py) will be ChangedStatus, if you're adding and changing in the same transaction. That's a good place to look for where the problem is. -- Steve Alexander Software Engineer Cat-Box limited
At 03:07 PM 4/22/01 +0100, Steve Alexander wrote:
As a simpler workaround, you can use your_object.commitSubtransaction() instead of redirecting to a new page.
Um, this shouldn't be the issue here. _SetAttributeFor() should be called when the attribute is set; it's not transaction-driven. Something weird is happening with Christian's situation that I haven't investigated yet.
You really should be able to create a new object and set its attributes in the same transaction. The status of the object (_v_status in DataSkin.py) will be ChangedStatus, if you're adding and changing in the same transaction. That's a good place to look for where the problem is.
Actually, the status should be AddedStatus, and it should stay that way throughout the transaction, unless the object gets deleted in the same transaction.
participants (3)
-
cs＠comlounge.net -
Phillip J. Eby -
Steve Alexander