[Zope-dev] z3c.form update issues

2009-02-21 Thread Roger Ineichen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] z3c.form update issues

2009-02-21 Thread Dan Korostelev
2009/2/21 Roger Ineichen d...@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
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] z3c.form update issues

2009-02-21 Thread Roger Ineichen
Hi Dan  

 Betreff: Re: [Zope-dev] z3c.form update issues
 
 2009/2/21 Roger Ineichen d...@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
 

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] z3c.form update issues

2009-02-21 Thread Dan Korostelev
2009/2/21 Roger Ineichen d...@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
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] z3c.form update issues

2009-02-21 Thread Dan Korostelev
2009/2/21 Dan Korostelev nad...@gmail.com:
 2009/2/21 Roger Ineichen d...@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
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] z3c.form update issues

2009-02-21 Thread Roger Ineichen
Hi Dan
  
 Betreff: Re: [Zope-dev] z3c.form update issues
 
 2009/2/21 Dan Korostelev nad...@gmail.com:
  2009/2/21 Roger Ineichen d...@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
 

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] z3c.form update issues

2009-02-21 Thread 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
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] z3c.form update issues

2009-02-21 Thread Stephan Richter
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
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )