-
1. Re: pages.xml can be overpowerd by a javascrip rerender
joblini Dec 18, 2008 8:06 PM (in response to timerons)Hi Joe,
Since you are using a4j:support you may find the following information helpful:
5.4.2. Queue and Traffic Flood Protection in the Richface's reference.
7.11. Concurrent calls to conversational components in the Seam reference.
-
2. Re: pages.xml can be overpowerd by a javascrip rerender
timerons Dec 19, 2008 9:19 AM (in response to timerons)hello ingo
thanks for your replay.
now i changed the line
<a4j:support event="onchange" reRender="selectUnderlyingForm"/>to
<a4j:support event="onchange" reRender="issueSizeDecorator"/>where issueSizeDecorator is the id of the td element <s:decorate id="issueSizeDecorator">
i still got the same problem.
using the eventsQueue would be a solution but as click on the link below:
<h:commandButton styleClass="submit" value="#{messages['requestIndicativePrice']}" id="requestIndicativeButton" action="#{productCreationCtrl.requestIndicativePrice()}" />
i have no chance to name a eventsQueuein my understanding seam should stop rendering the page (answer ajax requests) as soon as i come into the pages.xml
i record with
live http headers
the traffic, there i saw that first the render goes to the server and the the button. i am pretty sure that the response of the first request is send back to the browser an causes the browser to stay.additional information:
the input box has a box at the bottom with the old values i added earlier. as the focus stays on that box the value is not selected till i change the focus to the button to leave the page. this causes a very short delay of the two events.in the docu it says:
Conversational components don't allow real concurrent access therefore Seam queues each request to process them serially. This allows each request to be executed in a deterministic fashion.if this is right i can't may self explain why we do have these problems...