[Seaside] no-post submit button

[Avi Bryant]

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