AW: Re: [Seaside] cancel button in canvas

seaside_list at seaside_list at
Thu Apr 20 06:47:55 UTC 2006


seems I am getting things wrong and I can learn an important lesson here.

>As far as I understand the use of a cancel-callback means:
>- you directly commit changes from the input-field callbacks to the model.
>- you don't validate changes before committing to the model.

That is exactly what I don't want to do: neither validate nor commit to the model, just leave the page without any validation errors or even worse some of my erronous data saved into the model.

My understanding to this point was that registering a cancel callback provides exactly that: the page can be left, no data is validated or committed. Just go out of this dialog and let me do something else.

Under WAHtmlRenderer our application reacted exactly like that. Does your comment imply that we need to change something here? First tests show that this is not the case: everything seems to work as before...

>A cancel-button should never allow any side-effects, and the use of a

Exact. No side-effects wanted.

>cancel-callback cannot grantee that: side-effects do easily happen
>during validation (the form has to be redisplayed again), when picking
>a date from a date-picker (the form is submitted), input-fields are
>serialized trough ajax-actions, etc.

Are you sure about this? My observation in old-style WAHtmlRenderer was that using a cancel-callback can easily avoid all this.



More information about the Seaside mailing list