13 messages in org.apache.struts.userRe: Shale: onclick="disabled='true';"...| From | Sent On | Attachments |
|---|---|---|
| Jason Vincent | May 11, 2006 9:41 am | |
| James Reynolds | May 11, 2006 9:49 am | |
| Craig McClanahan | May 11, 2006 10:59 am | |
| Jason Vincent | May 11, 2006 12:20 pm | |
| Jason Vincent | May 11, 2006 12:21 pm | |
| James Reynolds | May 11, 2006 12:39 pm | |
| Michael Jouravlev | May 11, 2006 1:17 pm | |
| Craig McClanahan | May 11, 2006 2:04 pm | |
| Michael Jouravlev | May 11, 2006 2:17 pm | |
| Craig McClanahan | May 11, 2006 2:28 pm | |
| Michael Jouravlev | May 11, 2006 2:56 pm | |
| Craig McClanahan | May 11, 2006 3:02 pm | |
| Richard Wallace | May 11, 2006 8:47 pm |
| Subject: | Re: Shale: onclick="disabled='true';" not calling Action Method. (stopping double click) | |
|---|---|---|
| From: | Michael Jouravlev (jmi...@gmail.com) | |
| Date: | May 11, 2006 2:56:17 pm | |
| List: | org.apache.struts.user | |
On 5/11/06, Craig McClanahan <crai...@apache.org> wrote:
On 5/11/06, Michael Jouravlev <jmi...@gmail.com> wrote:
On 5/11/06, Craig McClanahan <crai...@apache.org> wrote:
On 5/11/06, Michael Jouravlev <jmi...@gmail.com> 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 ;-)