> > 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
> > ;-)
>
> Why? Assuming that you want the user experience to be a cancel
> button rather than a cancel link, I only see three options:
>
> - split the cancel button into its own form. Not always possible or
> desirable.
> - add a layer of indirection to all of the input callbacks (eg,
> capture the values locally and then apply them to the model only on a
> save callback)
> - have a specialized cancel callback
>
> The third usually leads to the least code and is the easiest to
> understand overall, IMO. What's the smell?
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.
For simple application it might be reasonable, however I guess that
for most productive applications we have to be careful about these
things.
A cancel-button should never allow any side-effects, and the use of a
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.
I agree it is a very cool feature that probably no other web-framework
is able to offer: still, in my opinion its use is rather limited, also
considering that there are tools (Mewa, Magritte) that help you build
editors with all the features you wish (save, cancel, validate, detect
and merge concurrent modifications, etc).
How many times did you use a cancel-callback or a link to cancel a
form? I only remember once.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Locked
