RE: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click)
The first thought that occurs to me is, how about binding the button's JSF 'disabled' attribute to a boolean property on your backing bean? As part of the button's action method, you could set the boolean to true, thereby disabling the button when the page reloads. -Original Message- From: Jason Vincent [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 10:42 AM To: user@struts.apache.org Subject: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click) Hi all, My project spec is asking me to disable form buttons once they are clicked. It seemed easy to me, just add onclick=disabled='true' to the commandButton. But as anything I've found with JSF, it isn't that easy. When I do this, the action method isn't being called after it passes validation. If I remove the onclick attribute, the form works fine; so I know it isn't a logic failure in the ViewController. I noticed that JSF inserts some of its own onclick logic to the button too. So I thought I'd try to disable the button by using the onsubmit attribute of the form tag. This also had the same behavior. What is going on here? Is disabling the button changing the submitted request parameters? Thanks all, Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click)
On 5/11/06, Jason Vincent [EMAIL PROTECTED] wrote: Hi all, My project spec is asking me to disable form buttons once they are clicked. It seemed easy to me, just add onclick=disabled='true' to the commandButton. But as anything I've found with JSF, it isn't that easy. When I do this, the action method isn't being called after it passes validation. If I remove the onclick attribute, the form works fine; so I know it isn't a logic failure in the ViewController. I noticed that JSF inserts some of its own onclick logic to the button too. So I thought I'd try to disable the button by using the onsubmit attribute of the form tag. This also had the same behavior. AFAIK, the custom onclick code supplied by JSF is only on the *hyperlink* component (h:commandLink, not on the *button* component (h;commandButton). Are you sure you're not confusing the two? What is going on here? Is disabling the button changing the submitted request parameters? Thinking it through, yes it actually *does* change the submitted request parameters. According to the HTML specification, disabled input controls are *not* included in the request attributes submitted to the server. Therefore, disabling the submit button will mean that the request parameter telling the server which button was clicked is not included -- which means JSF can't tell which command component submitted the form -- which means it has no way to know what action to invoke. I'd look for a strategy involving capturing the *second* click rather than the first one, so you can make sure the original request is submitted with no modifications. Thanks all, Jason Craig
Re: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click)
hmmm that isn't going to solve my issue. I don't want the button disabled on reload. I only want it to be disabled from the time the user clicked the button, until the time the server is able to send back a response. Here is an example: On a login form... enter username and pwd and click the submit button. While the server is processing the login form (the IE globe is spinning) the button becomes disabled so that the user can't resubmit the same login form. I'm more curious about how setting a DOM property on a element would change the way it is handled on the server side. Thanks for the try though, Jason On 5/11/06, James Reynolds [EMAIL PROTECTED] wrote: The first thought that occurs to me is, how about binding the button's JSF 'disabled' attribute to a boolean property on your backing bean? As part of the button's action method, you could set the boolean to true, thereby disabling the button when the page reloads. -Original Message- From: Jason Vincent [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 10:42 AM To: user@struts.apache.org Subject: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click) Hi all, My project spec is asking me to disable form buttons once they are clicked. It seemed easy to me, just add onclick=disabled='true' to the commandButton. But as anything I've found with JSF, it isn't that easy. When I do this, the action method isn't being called after it passes validation. If I remove the onclick attribute, the form works fine; so I know it isn't a logic failure in the ViewController. I noticed that JSF inserts some of its own onclick logic to the button too. So I thought I'd try to disable the button by using the onsubmit attribute of the form tag. This also had the same behavior. What is going on here? Is disabling the button changing the submitted request parameters? Thanks all, Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click)
Thanks Craig... that explains it. thanks, Jason On 5/11/06, Jason Vincent [EMAIL PROTECTED] wrote: hmmm that isn't going to solve my issue. I don't want the button disabled on reload. I only want it to be disabled from the time the user clicked the button, until the time the server is able to send back a response. Here is an example: On a login form... enter username and pwd and click the submit button. While the server is processing the login form (the IE globe is spinning) the button becomes disabled so that the user can't resubmit the same login form. I'm more curious about how setting a DOM property on a element would change the way it is handled on the server side. Thanks for the try though, Jason On 5/11/06, James Reynolds [EMAIL PROTECTED] wrote: The first thought that occurs to me is, how about binding the button's JSF 'disabled' attribute to a boolean property on your backing bean? As part of the button's action method, you could set the boolean to true, thereby disabling the button when the page reloads. -Original Message- From: Jason Vincent [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 10:42 AM To: user@struts.apache.org Subject: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click) Hi all, My project spec is asking me to disable form buttons once they are clicked. It seemed easy to me, just add onclick=disabled='true' to the commandButton. But as anything I've found with JSF, it isn't that easy. When I do this, the action method isn't being called after it passes validation. If I remove the onclick attribute, the form works fine; so I know it isn't a logic failure in the ViewController. I noticed that JSF inserts some of its own onclick logic to the button too. So I thought I'd try to disable the button by using the onsubmit attribute of the form tag. This also had the same behavior. What is going on here? Is disabling the button changing the submitted request parameters? Thanks all, Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click)
Oh, I totally missed the point. Best of luck. -Original Message- From: Jason Vincent [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 1:21 PM To: Struts Users Mailing List Subject: Re: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click) hmmm that isn't going to solve my issue. I don't want the button disabled on reload. I only want it to be disabled from the time the user clicked the button, until the time the server is able to send back a response. Here is an example: On a login form... enter username and pwd and click the submit button. While the server is processing the login form (the IE globe is spinning) the button becomes disabled so that the user can't resubmit the same login form. I'm more curious about how setting a DOM property on a element would change the way it is handled on the server side. Thanks for the try though, Jason On 5/11/06, James Reynolds [EMAIL PROTECTED] wrote: The first thought that occurs to me is, how about binding the button's JSF 'disabled' attribute to a boolean property on your backing bean? As part of the button's action method, you could set the boolean to true, thereby disabling the button when the page reloads. -Original Message- From: Jason Vincent [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 10:42 AM To: user@struts.apache.org Subject: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click) Hi all, My project spec is asking me to disable form buttons once they are clicked. It seemed easy to me, just add onclick=disabled='true' to the commandButton. But as anything I've found with JSF, it isn't that easy. When I do this, the action method isn't being called after it passes validation. If I remove the onclick attribute, the form works fine; so I know it isn't a logic failure in the ViewController. I noticed that JSF inserts some of its own onclick logic to the button too. So I thought I'd try to disable the button by using the onsubmit attribute of the form tag. This also had the same behavior. What is going on here? Is disabling the button changing the submitted request parameters? Thanks all, Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click)
On 5/11/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/11/06, Jason Vincent [EMAIL PROTECTED] wrote: According to the HTML specification, disabled input controls are *not* included in the request attributes submitted to the server. Therefore, disabling the submit button will mean that the request parameter telling the server which button was clicked is not included Unless Javascript is used for form's data collection and submission. I'd look for a strategy involving capturing the *second* click rather than the first one, so you can make sure the original request is submitted with no modifications. You mean, to resubimit the same request? What is the point? Will not it be the same anyway? Isn't it the task of the business layer to decide what to do with the second submit (say, add CD to the basket then again add CD to the basket to make two of them, etc). Nah, I would not like that. I don't use Struts token feature for the same reason: my buseness rules may allow resubmit as add one more. Seems that Shale (JSF?) uses Javascript anyway, so why not to use it to collect data from the form? It will allow to make sync and async requests to be processed alike. Also, is it possible to lock the server-side bean on a framework level, so it would be guaranteed that the bean won't get second request until the first one is serviced and responded to? Will a simple synchronized do? Or maybe to somehow swallow all identical (up to params) requests to the same resource while the resource services the first request? Kind of like Windows compresses several mouse events into one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click)
On 5/11/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 5/11/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/11/06, Jason Vincent [EMAIL PROTECTED] wrote: According to the HTML specification, disabled input controls are *not* included in the request attributes submitted to the server. Therefore, disabling the submit button will mean that the request parameter telling the server which button was clicked is not included Unless Javascript is used for form's data collection and submission. I'd look for a strategy involving capturing the *second* click rather than the first one, so you can make sure the original request is submitted with no modifications. You mean, to resubimit the same request? What is the point? As I understand it, the goal of the exercise is to *prevent* the second submit from occurring, while still allowing the first submit to complete properly. Will not it be the same anyway? Isn't it the task of the business layer to decide what to do with the second submit (say, add CD to the basket then again add CD to the basket to make two of them, etc). Nah, I would not like that. I don't use Struts token feature for the same reason: my buseness rules may allow resubmit as add one more. Seems that Shale (JSF?) uses Javascript anyway, Actually, it's the Command Link component that does this (i.e. when you want a hyperlink to submit the form), because there is no way to implement this at all without using JavaScript. The Command Button component (i.e. a normal submit button) does not use JavaScript. so why not to use it to collect data from the form? It will allow to make sync and async requests to be processed alike. Also, is it possible to lock the server-side bean on a framework level, so it would be guaranteed that the bean won't get second request until the first one is serviced and responded to? Will a simple synchronized do? Synchronizing might work *if* you were talking about the same instance of the backing bean -- but that is not going to be effective if you are using request scoped backing beans. In Struts terms, it would be like trying to synchronize on a property setter of a request-scoped ActionForm -- that will not catch the duplicate submit scenario because each request woud get its own instance. Craig Or maybe to somehow swallow all identical (up to params) requests to the same resource while the resource services the first request? Kind of like Windows compresses several mouse events into one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click)
On 5/11/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/11/06, Michael Jouravlev [EMAIL PROTECTED] wrote: Also, is it possible to lock the server-side bean on a framework level, so it would be guaranteed that the bean won't get second request until the first one is serviced and responded to? Will a simple synchronized do? Synchronizing might work *if* you were talking about the same instance of the backing bean -- but that is not going to be effective if you are using request scoped backing beans. In Struts terms, it would be like trying to synchronize on a property setter of a request-scoped ActionForm -- that will not catch the duplicate submit scenario because each request woud get its own instance. Yep, I meant session-scoped beans. JSF is more tolerant to session-scoped beans than Struts, or even prefers them over request scoped. So this might work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click)
On 5/11/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 5/11/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/11/06, Michael Jouravlev [EMAIL PROTECTED] wrote: Also, is it possible to lock the server-side bean on a framework level, so it would be guaranteed that the bean won't get second request until the first one is serviced and responded to? Will a simple synchronized do? Synchronizing might work *if* you were talking about the same instance of the backing bean -- but that is not going to be effective if you are using request scoped backing beans. In Struts terms, it would be like trying to synchronize on a property setter of a request-scoped ActionForm -- that will not catch the duplicate submit scenario because each request woud get its own instance. Yep, I meant session-scoped beans. JSF is more tolerant to session-scoped beans than Struts, or even prefers them over request scoped. So this might work. Might indeed (although you would still need the server side logic to detect the second submit and ignore it somehow), but I'd likely want to have a client side solution in place too, even if I implemented this, to improve the user experience. IMHO, session scoped backing beans in JSF have the same set of problems (as well as the same set of potential benefits) as session scoped form beans in Struts -- so the same tradeoff decisions apply in both cases. Personally, I try to use request scope for JSF backing beans (i.e. the equivalent of Action+ActionForm, or what WW2 considers to be an action instance) in my apps, and only store session scoped state for cases where I need it for a defined period of time (i.e. the conversational state in a Shale Dialog, for example, where it'll get thrown away for me when the dialog is completed). Craig
Re: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click)
On 5/11/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/11/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 5/11/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/11/06, Michael Jouravlev [EMAIL PROTECTED] wrote: Also, is it possible to lock the server-side bean on a framework level, so it would be guaranteed that the bean won't get second request until the first one is serviced and responded to? Will a simple synchronized do? Synchronizing might work *if* you were talking about the same instance of the backing bean -- but that is not going to be effective if you are using request scoped backing beans. In Struts terms, it would be like trying to synchronize on a property setter of a request-scoped ActionForm -- that will not catch the duplicate submit scenario because each request woud get its own instance. Yep, I meant session-scoped beans. JSF is more tolerant to session-scoped beans than Struts, or even prefers them over request scoped. So this might work. Might indeed (although you would still need the server side logic to detect the second submit and ignore it somehow), but I'd likely want to have a client side solution in place too, even if I implemented this, to improve the user experience. Is it possible to put all incoming requests into the map, so after a request has been serviced (response has been returned to the browser), it is removed from the map. When another request comes, we can use either soft comparison (same base URL) or strong comparison (same URL + params + method). If the incoming request is in the map already, we wait for response and return it in the same thread as the latter request (client has abandoned the first request anyway). So, we would need a separate map-controlling thread. Incoming threads would wait on request instance in the map. When response is ready, all threads but the last one would be terminated, the last one would return the response. Um, maybe instead of a map of requests it should rather be a map with lists of similar requests... Just a thought. The point is: do not process the same (whatever same is) request until the prior one has been serviced. only store session scoped state for cases where I need it for a defined period of time (i.e. the conversational state in a Shale Dialog, for example, where it'll get thrown away for me when the dialog is completed). How do you know that dialog is completed? :-) What if a user hasn't clicked Done or Cancel? Do you have a window close event listener or something or a page change listener? Anyway, Struts Dialogs wizard sample works the same ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click)
Craig McClanahan wrote: On 5/11/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 5/11/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/11/06, Jason Vincent [EMAIL PROTECTED] wrote: According to the HTML specification, disabled input controls are *not* included in the request attributes submitted to the server. Therefore, disabling the submit button will mean that the request parameter telling the server which button was clicked is not included Unless Javascript is used for form's data collection and submission. I'd look for a strategy involving capturing the *second* click rather than the first one, so you can make sure the original request is submitted with no modifications. You mean, to resubimit the same request? What is the point? As I understand it, the goal of the exercise is to *prevent* the second submit from occurring, while still allowing the first submit to complete properly. From what I understand that is the intention. I ran into the same thing trying to use the this.enabled = false; bit of javascript, but I ran into the same problems as the original poster. The solution I came up with was to do something like the following (in clay): script var formSubmitted = false; /script input type=submit value=Submit jsfid=commandButton onclick=if (formSubmitted) return false; formSubmitted = true; / This will work on commandLinks as well. The javascript that JSF uses will be put after any that is specified in the onclick javascript, at least with myfaces. The only thing this doesn't do is change the way the button is displayed so it also looks disabled. But it does stop the form from being accidentally submitted by a double click. Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
