I originally tried XML, but never gave much clarity to the CDATA route (good idea IMHO). The real upside of exploring the use of response headers though is that you can have a specific action or event in mind that may have it's own response, but at the same time you may utilize observers to update other parts.
With splitting up the body, you can run into issues since any valuechangelistener, actionlistener, method, etc could write directly to the body-- and we should let them do that, so we push this multiple encodes out of the body and into the headers, allowing some methodexpression to actually write back JSON or do reverse JS function invocation on the client *while* updating 5 other parts of the page. An example would be an order entry system where you assign JS event listeners to quantity changes that invokes a ValueChangeListener on the server, which does two things: 1) Tells JSF to re-render the div for order total 2) Possibly report/re-render issues with that line item, such as B/O status 3) Push JavaScript to the client to highlight the quantity area In the case of 1 and 2, they would be written to the response headers, allowing the ValueChangeListener to write whatever JS, JSON, XML, or HTML it wants to without being tied to the rules of UIComponent's encoding strategy. -- Jacob >Jacob (as he pointed out above) came up with what I think a rather >clever idea - using multiple HTTP response headers to embed >the multiple response sections. Very untraditional, but I think it'll >work very well and scale nicely. > >-- Adam > >On 5/2/06, Travis Reeder <[EMAIL PROTECTED]> wrote: >> >> >> > > Good point, this could easily be moved into >AjaxRendererUtils.encodeAjax >> > > since most of the form components just call back to that anyways to >> handle >> > > common cases. I was heading in a different direction with the generic >> > > listener update, where it would send the response wrapper and put the >> pay >> > > dirt in a cdata section, but it may be easier to just return different >> types >> > > of responses depending on the component. >> > >> > I'm not enthused about that - for one thing, it makes >> > it essentially impossible to send responses from two different >> > components in response to one request. And that's so >> > incredibly useful that you really shouldn't shut the door on it. >> > >> > IMO, MyFaces should just pick a blessed format for sending >> > responses that is flexible enough to support multiple responses >> > per request (and sending back at least both XML and HTML >> > content, and preferably also embedded JSON), and just tell >> > people to stick with that. >> > >> > Regards, >> > Adam >> > >> > >> >> You are absolutely correct Adam, and you reminded me why it is the way it >> is. The current way *does* support a response containing multiple >> components, which is the case with the CommandButtonAjax component that >will >> return multiple errors or multiple successes for all the components in the >> corresponding form. The client side script also supports this too. >> >> So as you suggested, it may be best to put HTML and JSON responses in CDATA >> sections and stick to the standard response format. >> >> Travis >> >>
