Lukas,
thanks for your answer.
>I guess the reason this is missing, is that nobody ever needed it. In
>my opinion, the need of a cancel-callback is a sign of a code-smell
>;-)
interesting view ;-) Most PC users are pretty used to having the choice between accepting changes they did on a page and to throw away what they did. A cancel button is kind of a logical rollback to my changes on a dialog/page. This has nothing to do with a code smell but with user interfaces and workflows. You might be speaking of design smells and present another idea of what would be a good way to give your user a means of throwing away their last changes to business data combined with a secure feeling of not having done any harm to the system. A cancel button has done a good job in this for quite some years now, at least this is what my experience tells me...
>However you can add a method like the following one, to get the
>desired behavior:
>
>WASubmitButtonTag>>cancelCallback: aBlock
> self attributes at: 'name' put: (canvas callbacks
>registerCancelActionCallback: aBlock)
I used something very similar (reusing my code from a WAHtmlRenderer - based class), and it works fine. I was just astonished that this has not been implemented yet. Maybe you are right and cancel buttons aren't used much in seaside applications, but still I disagree with your code smell argument ;-)
Cheers
Joachim
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Locked
