[jifty-devel] Problem with disabling buttons after submit in forms

[Jesse Vincent]

On Aug 17, 2007, at 3:38 PM, Edward Funnekotter wrote:

> Hi all,
>
> Now that I added support for 'onchange' within form fields, I am  
> now running into a small problem with submit buttons automatically  
> being disabled when one of these other triggers causes a submit.   
> If you are refreshing the entire form after the submit it isn't a  
> problem, but if you just want to change a portion of the form that  
> is in its own region then the disabled button does not become re- 
> enabled.  Here is simple example:
>
> *FORM START*
>
>   *Action1Field1*
>   *Action1Field2*
>
>   *RegionA START*
>
>       *Action2Field1*
>       *Aciton2Field2 - onchange => {submit => Action2, refresh_self  
> => 1*
>
>   *RegionA END*
>
>   *SubmitButton - onclick => {submit => undef} *
>
> *FORM END*
>
>
> The idea is that RegionA can be changed based on Action2Field2's  
> settings without submitting and reloading the entire form.  In my  
> case, the form is fairly large and it is a lot smoother if I can  
> just refresh a small part of it.  The problem is that since I am  
> just refreshing RegionA, the SubmitButton is never redrawn.  The  
> act of submitting Action2 caused the button to be disabled due to  
> the way jifty.js performs updates.
>
> I have gone through the javascript code and understand what it is  
> doing, but I would like advice on the best way to fix this - or  
> perhaps there is a much better way to do the type of thing I am  
> doing.  I did experiment with just calling the '  
> a.enable_input_fields()' in a similar manner to if a submission  
> fails and while this works for me, I doubt that it will work in  
> general depending on how the DOM changed during the update.
>
> Here are a few options that spring to mind for the fix:
> Do not automatically disable all buttons in the form that have this  
> action.  Only disable the actual element that triggered the  
> submit.  I have a feeling that this might defeat the reason of the  
> disable (so you couldn't resubmit while an update is outstanding).
> Keep a list of all disabled elements that fall outside of the  
> fragment being replaced.  Re-enable these on successful completion  
> of the update.
> Keep a list of all disabled elements regardless of where they are  
> and re-enable those even if they have been replaced.  If they  
> aren't in the DOM, I don't think it would matter...


I think #3 sounds the most sane. (I'll note that you probably want to  
re-enable on the _failure_ of the update, too. Otherwise a server  
error will lock the page.

Thanks very much for thining hard about this and digging into it.

-jesse


> While I describe a specific case that is bothering me, I suspect  
> that this problem will always happen if a submission does not  
> replace the form that it is part of.
>
> Like I said, I am happy to fix this, but would like some feedback  
> before I embark on any changes.
>
> Ed
>
> _______________________________________________
> jifty-devel mailing list
> jifty-devel at lists.jifty.org
> http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20070820/e2ccf548/PGP.pgp