So the caller would do the responseComplete after rendering the noop, right? If so, that looks MUCH better to me.. +1
On Mar 14, 2011, at 5:06 PM, Yuan Gao <yuan....@oracle.com> wrote: > hi, > > I agree that we are trying to do too much in a method. Also talked with Blake > about it. How about we leave the script and redirect to the caller, in this > method we only do the noop writing? We don't do the complete response either. > How do you like this then? > > /** > * This method writes a <noop/> to the response. > * > * @param context the FacesContext > * @throws IOException > */ > public static void renderNoopResponse(FacesContext context) throws > IOException > > Thanks, > -Yuan > > On 3/14/2011 7:17 AM, Scott O'Bryan wrote: >> Yes, I agree Andy. That proposed API scared me a bit because it >> seemed that we were trying to do to much in a single method call. >> There was a redirect message, a script and noop params. If we can >> separate them and use the real "redirect" functionality built into the >> EC, I'm good. :D >> >> On Mar 14, 2011, at 7:50 AM, Andy Schwartz<andy.g.schwa...@gmail.com> wrote: >> >>> Hi Yuan - >>> >>> On Mon, Mar 14, 2011 at 3:10 AM, Yuan Gao<yuan....@oracle.com> wrote: >>>> I like your comments. As for the names, how about >>>> renderNoopAndCompleteResponse()? >>> That's definitely the clearest of the names that we have discussed. :-) >>> >>> If we go with "render", I can see three options: >>> >>> 1. renderNoopAndCompleteResponse() >>> 2. renderNoopResponse() >>> 3. renderNoop() >>> >>> I prefer the more concise forms (#2 or #3), though I think this mostly >>> comes down to personal taste. Any of these are fine by me. >>> >>> I am curious about some of the questions that Scott raised, eg: >>> >>> - Should we consider just having FacesContext.responseComplete() >>> detect the empty response and automatically send a noop response? >>> (Interesting idea, though I am worried that this might be just a bit >>> too much magic. Think I like the idea of having an explicit API to >>> call.) >>> >>> - Do we need a new method for the redirect case? (Seems like this is >>> sufficiently covered by ExternalContext.redirect()). >>> >>> Andy
