Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <44582E81.2090702@hookom.net>
Date: Tue, 02 May 2006 23:16:01 -0500
From: Jacob Hookom <jacob@hookom.net>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: MyFaces Development <dev@myfaces.apache.org>
Subject: Re: AJAX functionality in MyFaces
References: <W2909424127214961146629339@webmail21>
In-Reply-To: <W2909424127214961146629339@webmail21>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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:jacob@hookom.net]
>> 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, *jacob@hookom.net <mailto:jacob@hookom.net>* 
>>> <jacob@hookom.net <mailto:jacob@hookom.net>> 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, jacob@hookom.net <mailto:jacob@hookom.net>
>>>     <jacob@hookom.net <mailto:jacob@hookom.net>> 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, jacob@hookom.net <mailto:jacob@hookom.net>
>>>     <jacob@hookom.net <mailto:jacob@hookom.net>> 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 <treeder@gmail.com
>>>     <mailto:treeder@gmail.com>> 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