I'd like to have a submit button in a form that would not trigger any callbacks for the form inputs. It is for cancel action - much easier just to throw all the data away than to save them and then try to rollback a transaction or something.
I came as far as poking around WACallbackStore>>processRequest: but I'd appreciate some help with this, thanks
rado
On May 29, 2004, at 5:20 AM, radoslav hodnicak wrote:
I'd like to have a submit button in a form that would not trigger any callbacks for the form inputs. It is for cancel action - much easier just to throw all the data away than to save them and then try to rollback a transaction or something.
Yes, as long as the form is simple enough. Complex edit pages often involve multiple request/responses before the changes are finally committed or cancelled, and so I usually think of the problem in more general terms and end up needing some kind of rollback anyway (not that I've found a solution for this I'm totally satisfied with).
I came as far as poking around WACallbackStore>>processRequest: but I'd appreciate some help with this, thanks
How about this: you could have a special #registerCancelCallback: that worked just like #registerActionCallback:, but recorded the key in a new ivar:
requestCancelCallback: aBlock ^ cancelKey := self registerActionCallback: aBlock Then you could check for this when processing the request:
processRequest: aRequest (cancelKey notNil and: [aRequest fields includesKey: cancelKey]) ifTrue: [^ (callbacks at: cancelKey) trigger]. ...
Then you just have to add #cancelButton to HtmlRenderer that uses #registerCancelCallback: instead of #registerActionCallback: when creating the submit button.
Actually, you probably want to allow multiple cancelKeys, but that's an obvious extension.
The approach in 2.5 would be somewhat different - actually I'm not really happy with the way action callbacks work now in 2.5, so this might be the right impetus to rework them. It would be nice to somehow generalize the above, and be able to register callbacks both with an order (action callbacks should happen after value callbacks), and the ability to suppress others (submit button callbacks should suppress default form callbacks, cancel callbacks should suppress value callbacks).
But the #cancelButton interface would remain the same, and that seems like a useful addition to the base framework. I'll add it to the TODO list.
Avi
seaside@lists.squeakfoundation.org