myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <werner.p...@gmail.com>
Subject Re: submit and ajax request will not be queued together
Date Fri, 10 Sep 2010 10:25:57 GMT
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.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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>



Mime
View raw message