Smalltalk › Frameworks & Tools › Seaside › Seaside General

callbacks of disabled submit buttons

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Sebastian Sastre-2

callbacks of disabled submit buttons

Hi there,
fact: when you disable a submit button it's not going to be serialized.
problem: you want to disable the button after the click but you also want to
execute its callback.

This is often needed. For instance a login form. You want the user to login and
wait for the result. The disable of the button is just to make it idempotent
until the result is received preventing silly server load.
Another example is a "confirm purchase" kind of button where a capture of money
is made.

Any ideas?

sebastian

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli

Re: callbacks of disabled submit buttons

> fact: when you disable a submit button it's not going to be serialized.

Indeed, see http://bit.ly/2J2Oma.

> This is often needed. For instance a login form. You want the user to login and
> wait for the result. The disable of the button is just to make it idempotent
> until the result is received preventing silly server load.

You are looking for read-only, I guess. The difference between
disabled and read-only is described a bit above: http://bit.ly/4xG24Y.

> Another example is a "confirm purchase" kind of button where a capture of money
> is made.

I wouldn't count on the we client, to make it secure you *have to*
prevent a double confirmation on the server, for example by checking
in your model or using #isolate:

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sebastian Sastre-2

RE: callbacks of disabled submit buttons

> make it idempotent
> > until the result is received preventing silly server load.
>
> You are looking for read-only, I guess. The difference between
> disabled and read-only is described a bit above: http://bit.ly/4xG24Y.
>
That sounds about right. Figuring out how...

> > Another example is a "confirm purchase" kind of button
> where a capture of money
> > is made.
>
> I wouldn't count on the we client, to make it secure you *have to*
> prevent a double confirmation on the server, for example by checking
> in your model or using #isolate:
>
> Cheers,
> Lukas

sure. What I mean is both. Actually is decided by the server but as an extra
measure I want additionally to prevent UI side excess of clicks.

Never bad to remember it anyway.

thanks for the pointer
sebastian

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sebastian Sastre-2

RE: callbacks of disabled submit buttons

Ok, here I go..

for the record:
f* buttons won't work as supossed with readonly. Is nothing to do with Seaside.
They should, but they won't. Don't ask why.

So.. a way I've found to (almost) achieve this feature (without using ajax) is
to let the button enabled and observe the submit event. If the submit event was
already received (you need to store that state at DOM) then react stopping it to
prevent the extra POST's.
peace & love
sebastian

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Sebastian Sastre
> Enviado el: Friday, August 21, 2009 16:32
> Para: 'Seaside - general discussion'
> Asunto: RE: [Seaside] callbacks of disabled submit buttons
>
> > make it idempotent
> > > until the result is received preventing silly server load.
> >
> > You are looking for read-only, I guess. The difference between
> > disabled and read-only is described a bit above:
> http://bit.ly/4xG24Y.
> >
> That sounds about right. Figuring out how...
>
>
> > > Another example is a "confirm purchase" kind of button
> > where a capture of money
> > > is made.
> >
> > I wouldn't count on the we client, to make it secure you *have to*
> > prevent a double confirmation on the server, for example by checking
> > in your model or using #isolate:
> >
> > Cheers,
> > Lukas
>
> sure. What I mean is both. Actually is decided by the server
> but as an extra
> measure I want additionally to prevent UI side excess of clicks.
>
> Never bad to remember it anyway.
>
> thanks for the pointer
> sebastian
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside