myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ganesh <gan...@j4fry.org>
Subject Re: submit and ajax request will not be queued together
Date Tue, 07 Sep 2010 13:29:02 GMT
Hi Mark,

A standard form submit will always go through whether an AJAX request is running or not. There
is no queueing of no AJAX submits. You may consider disabling the button until the AJAX request
is successfull.

Best regards,
Ganesh

Mark Struberg schrieb:
> 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.punz@gmail.com> wrote:
> 
>> From: Werner Punz <werner.punz@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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
> 
>       
> 

-- 
"There are two kinds of people in the world, those who believe there are two kinds of people
and those who don't."
— Robert Benchley

Mime
View raw message