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]
