Hi all I fixed a z3c.form issue where util.Manager keys and values get append more then one time by calling update more then once on widgets or actions. For doing so, I implemented a UniqueOrderedKeys class for util.Manager._data_keys and a decorator which will prevent to override them. See z3c.form.util.py line: 120 Can you please review if this and let me know it this is compatible with our own z3c.form parts? My motivation to deep into this is to find a better way how we use the update track. I think we should separate the update process into a setup and execute concept. I have the feeling, but could not really tell it right now, that we need to separate execute for prevent calling execute more then once during calling update. Update should get called more then once at least if it comes to calculate button/handler conditions. Because it's possible that an action execute call manipulates something which will change the button condition which we need to recalculate within an action update call. Any hints/ideas about that. Or do you know a good use case for this problem. It also smells to me that the MultiWidget or the ObjectWidgets implementation could be more robust within a better update/execute concept. Regards Roger Ineichen _____________________________ END OF MESSAGE
2009/2/21 Roger Ineichen <dev@projekt01.ch>:
Hi all
I fixed a z3c.form issue where util.Manager keys and values get append more then one time by calling update more then once on widgets or actions.
For doing so, I implemented a UniqueOrderedKeys class for util.Manager._data_keys and a decorator which will prevent to override them. See z3c.form.util.py line: 120
Can you please review if this and let me know it this is compatible with our own z3c.form parts?
My motivation to deep into this is to find a better way how we use the update track. I think we should separate the update process into a setup and execute concept. I have the feeling, but could not really tell it right now, that we need to separate execute for prevent calling execute more then once during calling update.
Update should get called more then once at least if it comes to calculate button/handler conditions. Because it's possible that an action execute call manipulates something which will change the button condition which we need to recalculate within an action update call.
Any hints/ideas about that. Or do you know a good use case for this problem. It also smells to me that the MultiWidget or the ObjectWidgets implementation could be more robust within a better update/execute concept.
IIRC, the update and execute phases are already separated for actions (you call actions.update() for setup and actions.execute() for actual execting) and that fact is used in MultiWidget and many custom forms. -- WBR, Dan Korostelev
Hi Dan
Betreff: Re: [Zope-dev] z3c.form update issues
2009/2/21 Roger Ineichen <dev@projekt01.ch>:
Hi all
I fixed a z3c.form issue where util.Manager keys and values get append more then one time by calling update more then once on widgets or actions.
For doing so, I implemented a UniqueOrderedKeys class for util.Manager._data_keys and a decorator which will prevent to override them. See z3c.form.util.py line: 120
Can you please review if this and let me know it this is compatible with our own z3c.form parts?
My motivation to deep into this is to find a better way how we use the update track. I think we should separate the update process into a setup and execute concept. I have the feeling, but could not really tell it right now, that we need to separate execute for prevent calling execute more then once during calling update.
Update should get called more then once at least if it comes to calculate button/handler conditions. Because it's possible that an action execute call manipulates something which will change the button condition which we need to recalculate within an action update call.
Any hints/ideas about that. Or do you know a good use case for this problem. It also smells to me that the MultiWidget or the ObjectWidgets implementation could be more robust within a better update/execute concept.
IIRC, the update and execute phases are already separated for actions (you call actions.update() for setup and actions.execute() for actual execting) and that fact is used in MultiWidget and many custom forms.
Yes, I think we should carefully review this part and probably add action.update after action.execute. Right now, without looking at the code I think we do not update actions after execute. Which could end in bad action handler setup because of skipped action condition handling after execute actions. I'll see later if I take another look at that part. Regards Roger Ineichen _____________________________ END OF MESSAGE
-- WBR, Dan Korostelev
2009/2/21 Roger Ineichen <dev@projekt01.ch>:
we should carefully review this part and probably add action.update after action.execute. Right now, without looking at the code I think we do not update actions after execute. Which could end in bad action handler setup because of skipped action condition handling after execute actions.
I'll see later if I take another look at that part.
Ah, you mean the "update" method of the form base classes. Yeah, there's no action update performed after executions currently. But I don't think we should just add another updateActions call after execution as it can be quite expensive. The button actions call their widgets' update methods that performs another thousand of adaptations calls. :) However, the problem is very actual and I personally had it in some of my forms. The most obvious use case is when we use the "delete" button to delete all entries in the list and then we don't want to show the "delete" button anymore. One (probably nice) solution that comes in my mind is to make the form somehow aware if it needs to re-update its actions and to provide a way for the action handler to signal about that. Probably, a simple boolean form instance variable will do the trick :) -- WBR, Dan Korostelev
2009/2/21 Dan Korostelev <nadako@gmail.com>:
2009/2/21 Roger Ineichen <dev@projekt01.ch>:
we should carefully review this part and probably add action.update after action.execute. Right now, without looking at the code I think we do not update actions after execute. Which could end in bad action handler setup because of skipped action condition handling after execute actions.
... snip ...
One (probably nice) solution that comes in my mind is to make the form somehow aware if it needs to re-update its actions and to provide a way for the action handler to signal about that. Probably, a simple boolean form instance variable will do the trick :)
I just checked in a fix like I described above. It seems to work at leasts for tests.:-) Can you please review it? -- WBR, Dan Korostelev
Hi Dan
Betreff: Re: [Zope-dev] z3c.form update issues
2009/2/21 Dan Korostelev <nadako@gmail.com>:
2009/2/21 Roger Ineichen <dev@projekt01.ch>:
we should carefully review this part and probably add action.update after action.execute. Right now, without looking at the code I think we do not update actions after execute. Which could end in bad action handler setup because of skipped action condition handling after execute actions.
... snip ...
One (probably nice) solution that comes in my mind is to make the form somehow aware if it needs to re-update its actions and to provide a way for the action handler to signal about that. Probably, a simple boolean form instance variable will do the trick :)
I just checked in a fix like I described above. It seems to work at leasts for tests.:-) Can you please review it?
Yeah great, that's exactly what we need to do. Thanks a lot! Regards Roger Ineichen _____________________________ END OF MESSAGE
-- WBR, Dan Korostelev
On Saturday 21 February 2009, Dan Korostelev wrote:
One (probably nice) solution that comes in my mind is to make the form somehow aware if it needs to re-update its actions and to provide a way for the action handler to signal about that. Probably, a simple boolean form instance variable will do the trick :)
I like that idea, since I agree with your argument that updating actions can be expensive. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
On Saturday 21 February 2009, Roger Ineichen wrote:
I fixed a z3c.form issue where util.Manager keys and values get append more then one time by calling update more then once on widgets or actions.
For doing so, I implemented a UniqueOrderedKeys class for util.Manager._data_keys and a decorator which will prevent to override them. See z3c.form.util.py line: 120
Can you please review if this and let me know it this is compatible with our own z3c.form parts?
I would have simply cleared the entire manager upon update() again. Otherwise, how do you handle an item disappearing when update() is called again?
My motivation to deep into this is to find a better way how we use the update track. I think we should separate the update process into a setup and execute concept. I have the feeling, but could not really tell it right now, that we need to separate execute for prevent calling execute more then once during calling update.
I see what you are saying and I think you are right. However, a formal split may be enough. Could we not just set a flag called "wasExecuted"?
Update should get called more then once at least if it comes to calculate button/handler conditions. Because it's possible that an action execute call manipulates something which will change the button condition which we need to recalculate within an action update call.
Absolutely. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
participants (3)
-
Dan Korostelev -
Roger Ineichen -
Stephan Richter