Parameters needed to trigger decode in ajax request ?

[joachimhb]

Hello,

I am having some trouble with triggering the decode methods in Ajax requests (in a custom component).

I am doing the following with the request, but there seems to be something missing in order to trigger the decode methods to fire (encodeEnd are triggered on the components in the view, though).

What parameters need to be in place in order to make the post-back happen ?

JSFlot.AJAX.Submit = function(formId, event, url, options) {
 var query = JSFlot.AJAX.PrepareQuery(formId);
 var viewState = document.getElementById("javax.faces.ViewState");
 var encodedViewState = encodeURI(viewState.value);
 var rexp = new RegExp("\\+", "g");
 encodedViewState = encodedViewState.replace(rexp, "%2B");

 if (query) {
 log.debug("NEW AJAX REQUEST !!! with form: " + (query._form.id || query._form.name || query._form) + " URL: " + url);

 new Ajax.Request(url, {
 method: 'post',
 contentType: "application/x-www-form-urlencoded",
 parameters: {
 "org.jsflot.AJAX_REQUEST": true,
 "javax.faces.ViewState": encodedViewState,
 "com.sun.faces.VIEW": encodedViewState,
 "formName": formId,
 "client-id": options._clientId,
 "component-value": options._componentValue
 },
 onSuccess: function(transport) {
 log.debug("XHR successful. Response: " + transport.responseText);
 var json = transport.responseText.evalJSON();
 if(json.series && json.options && json.componentId) {
 var f = Flotr.draw($(json.componentId), json.series, json.options);
 }
 }
 });
 }
}

[nbelaevski]

Hi,

Please take a look:

AJAXREQUEST is identifier of the region to process.
j_id351 - identifier of a4j:support
myinput - contains 'a' letter

[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

[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 ?