I don't know of any performance increase, but the HTTP spec wants the application to return 200 for an OK w/ a body and a 204 for a bodyless OK.
The main problem you get with some HTTP clients/servers/intermediaries is when you have 204s *with* bodies, so you are probably OK w/ just returning 200 every time. I have worn the sysadmin hat though, and it has always suprises me how many problems arise w/ REST caches and HTTP proxies ( *not* browsers ) when apps ignore RFC 2616. Dennis Byrne >-----Original Message----- >From: Jacob Hookom [mailto:[EMAIL PROTECTED] >Sent: Wednesday, May 3, 2006 12:16 AM >To: 'MyFaces Development' >Subject: Re: AJAX functionality in MyFaces > >That's a warm fuzzy :-) > >Based on Martin's point, I did have the Filter buffer the body if the >request was an Async type. This should allow any components to be >rendered back in the header while allowing any code (component or other) >to write to the body. Would we get better performance or otherwise if >the buffer filter knew that no body was written and respond with a 204 >status? > >Thanks > >Dennis Byrne wrote: >> I do not know if it has been brought up in this discussion yet, but if any >> of you guys end up implementing the "header trick", you may want to force >> the server to return a 204 (no body) instead of a 200. >> >> I have been using the response header as a "poor man's Map" for a few months >> w/ non-faces and faces requests and it hasn't bit me yet. >> >> Dennis Byrne >> >> >>> -----Original Message----- >>> From: Jacob Hookom [mailto:[EMAIL PROTECTED] >>> Sent: Tuesday, May 2, 2006 08:29 PM >>> To: 'MyFaces Development' >>> Subject: Re: AJAX functionality in MyFaces >>> >>> Travis Reeder wrote: >>> >>>> With the XML solution, how would you capture content written >>>> directly to the response vs. content from multiple components? >>>> >>>> >>>> If I understand what you are asking correctly, I may have already >>>> answered it above with multiple responses from multiple components. >>>> >>> The use case though is non-components responding in the body. So at any >>> method, listener, action, etc, you could have code that writes content >>> to the response-- how is that intercepted/inserted in relation to the >>> larger XML schema you are defining for the body? >>> >>> >>>> Travis >>>> >>>> On 5/2/06, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>* >>>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: >>>> >>>> With the XML solution, how would you capture content written >>>> directly to the response vs. content from multiple >>>> components? We're really interested in providing a prototype for >>>> this for JSF 1.2, so if you guys think the XML body will work >>>> better, let us know. I'm just wondering how you would still get >>>> around needing to capture/buffer content written to the >>>> responsewriter in relation to the possibility of content from >>>> other UIComponents. >>>> >>>> >well, I wouldn't say that generally. If we can work around this >>>> >without a major downside, we should, I suppose. >>>> > >>>> >@Being Advantageous: Hmm.... Don't think there is any difference for >>>> >the end developer - if you have a client side javascript library >>>> doing >>>> >the parsing anyways... >>>> > >>>> >regards, >>>> > >>>> >Martin >>>> > >>>> >On 5/2/06, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: >>>> >> That's a good point, but AJAX requests are much smaller so the >>>> buffering of >>>> >the response isn't as dramatic as it would otherwise be on >>>> initial page load. >>>> >It's tricky to implement, but the trade-off to the end developer, >>>> I believe, >>>> >would be extremely advantagous. >>>> >> >>>> >> >The only problem I see with the header approach is that everything >>>> >> >needs to be processed and buffered upfront again. >>>> >> > >>>> >> >If you have a component that is processed at the end of a >>>> very, very >>>> >> >long component tree, it might as well be that you can't store the >>>> >> >response data in memory in the meantime. >>>> >> > >>>> >> >regards, >>>> >> > >>>> >> >Martin >>>> >> > >>>> >> >On 5/2/06, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: >>>> >> >> 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] >>>> <mailto:[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 >>>> >> >> >> >>>> >> >> >> >>>> >> >> >>>> >> > >>>> >> > >>>> >> >-- >>>> >> > >>>> >> >http://www.irian.at >>>> >> > >>>> >> >Your JSF powerhouse - >>>> >> >JSF Consulting, Development and >>>> >> >Courses in English and German >>>> >> > >>>> >> >Professional Support for Apache MyFaces >>>> >> >>>> > >>>> > >>>> >-- >>>> > >>>> >http://www.irian.at <http://www.irian.at> >>>> > >>>> >Your JSF powerhouse - >>>> >JSF Consulting, Development and >>>> >Courses in English and German >>>> > >>>> >Professional Support for Apache MyFaces >>>> >>>> >>>> >>> -- >>> -------------------------- >>> Sent from my FrankenBerry Wireless Handheld >>> >>> >>> >> >> >> >> > > >-- >-------------------------- >Sent from my FrankenBerry Wireless Handheld > >
