-
1. Re: Parameters needed to trigger decode in ajax request ?
nbelaevski May 25, 2009 10:42 AM (in response to joachimhb)Hi,
Please take a look:
AJAXREQUEST is identifier of the region to process.
j_id351 - identifier of a4j:support
myinput - contains 'a' letter -
2. Re: Parameters needed to trigger decode in ajax request ?
joachimhb May 26, 2009 6:27 AM (in response to joachimhb)Thank you very much! I missed the "formname: formname" parameter :)
"nbelaevski" wrote:
Hi,
Please take a look: <img src="http://i43.tinypic.com/2n23aco.png"></img>
AJAXREQUEST is identifier of the region to process.
j_id351 - identifier of a4j:support
myinput - contains 'a' letter -
3. Re: Parameters needed to trigger decode in ajax request ?
joachimhb May 27, 2009 8:21 AM (in response to joachimhb)Thank you very much for your answers, much appreciated.
I have a question though, that you might be able to give your opinions to.
When trying to implement a drag-and-drop functionality for the JSFlot chart library, I tried a few different Ajax approaches that were recommended in different placed on the web.
The fist I tried was the PhaseListenere approach, where the PhaseListener listens for the RESTORE_VIEW phase. The PhaseListener is then responsible for finding the component, and invoking methods on it and to render a response (which is generally generated seperately from the encodeBegin/encodeEnd methods that are part of the JSF lifecycle).
I found that this approach, although it works well and is rather efficient (the JSF Life Cycle is short-circuited near the beginning), it also breaks with the standard JSF lifecycle.
Since I wanted my component to trigger a ValueChangedEvent, I needed, though to consider all the steps in the LifeCycle, and I needed to make sure that whatever code was in the ValueChangedListener would be executed before the response was rendered.
I then opted to use the full JSF lifecycle, by submitting the form data along with the ViewState.
In doing this, while this approach seems more clean and clear, every component that was on the same page is getting their decode, encodeBegin and encodeEnd methods executed, rendering a complete response. Parsing the response with the DOM parser and replacing with Prototype is not a big challenge, though this approach seems to be just as "server-heavy" as a full page refresh.
Now, after that lengthy intro, here goes my question (which I found hard to actually write as a question :) ):
In choosing between these two steps, it seems to be that one can either choose from "high-speed PhaseListener approach", or a "clean and complete JSF lifecycle approach, that is a bit heavy on the server-side". The first does allow one to tailor the response specifically for a single XHR request, whereas the second allow JSF events to be fired appropriately and normal rendering to commence. The second part also makes it possible to rerender other elements in the DOM tree however, as the complete DOM tree is returned.
There seems to be something of a predicament. Choose between the fast and efficient AJAX-friendly approach where you tailor for AJAX, but break with JSF standards, or follow the JSF standards and lifecycle but break with the "fast AJAX way" of creating and handling the response ?