Ok after rechecking the code, please Mark check your code for following:
a normal commandButton normally is rendered to input type="submit" which also means regardless whether you return false or true in onclick a form submit will be issued automatically.

What I personally think could be following, you simply did not set
<h:commandButton type="button" but only <h:commandButton just as Ganesh iterated

but that is just a wild guessing here.

Werner


Am 07.09.10 14:34, schrieb Mark Struberg:
txs Werner,
I'll tinker together a small standalone test app until this evening. The 
problem seem that we FIRST call the ajax request (opening a small javascript 
yes/no dialog) and THEN the user hits the commandButton. You can try this by 
invoking a ajax method which calls a sleep(3) and hit the button in the 
meantime.

LieGrue,
strub

--- On Tue, 9/7/10, Werner Punz<werner.p...@gmail.com>  wrote:

From: Werner Punz<werner.p...@gmail.com>
Subject: Re: submit and ajax request will not be queued together
To: dev@myfaces.apache.org
Date: Tuesday, September 7, 2010, 12:06 PM
I also checked the queue testcodes on
my side. I have a testcase where a
server servlet delays the response for three seconds, but
it triggers
directly jsf.ajax.request. That is on the latest codebase.

What happens is following if I press the button multiple
times, the
requests are issued exactly after the delay which means the
requests are
definitely queued in while the original request is
running.
Are you using the jsf.ajax.request in conjunction with a
layer which
sits on top of it and maybe bypasses the core code or rolls
its own ajax
send scripts?

Werner


Am 07.09.10 13:55, schrieb Werner Punz:
Ok Mark I checked the code there should be no two
requests being sent
issue there, the code definitely enqueues while a
request is running,
and dequeues once the request has done its work.
But I do not want to rule out a bug here on code
level, but can you send
me a demo app so that I can have a look.
Btw. which version of the codebase are you on?

lG

Werner



Am 07.09.10 13:42, schrieb Werner Punz:
Am 07.09.10 13:26, schrieb Mark Struberg:
Hi!

We have a page which renders a confirmation
dialogue area with f:ajax
and this confirmation dialogue has a
h:commandButton.

Since our view restoration may take a bit it
happens that the user
might click fast enough on the commandbutton
while the ajax request is
still on the server. Thus we might have 2
parallel requests on the
same @ViewScoped bean. This is even more
troublesome if we use CDI
@ConversationScoped beans.

We looked at the jsf.js and it seems that
although concurrent f:ajax
requests get queued the submit via the
commandButton hits the server
unqueued.

Is this behaviour in sync with the spec?

There is a workaround to also only use f:ajax
with commandButtons, but
since I have to use this all the times it
could be easier to queue
submits also.

LieGrue,
strub




I will investigate it the first request should get
through unqueued the
second one has to go into the queue and wait while
the first one is
executing that is the expected behavior, let me
check if we have a
queuing error there.
There should be no request issued against the
server while another one
currently is on the server.


Werner















Reply via email to