That sounds good to me. You can keep this method (discouraging it being overridden unless absolutely necessary), and then perhaps one overridable method per RenderingResult enum?
--j On Thu, Jul 22, 2010 at 4:39 PM, <[email protected]> wrote: > I agree its a kind of kitchen sink approach to overridable method. > > One example I would be to have custom logic to show error message or > change encoding/content-type. > > What if l refactor the code to have more specific overriable methods for > each possible result status? Maybe then it could add more flexibility to > developers with the generic logic keep inside the > GadgetRenderingServlet. > > - Henry > > > On 2010/07/22 23:28:45, johnfargo wrote: > >> http://codereview.appspot.com/1665054/diff/1/2 >> File >> > > > java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/GadgetRenderingServlet.java > >> (right): >> > > http://codereview.appspot.com/1665054/diff/1/2#newcode125 >> > > > java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/GadgetRenderingServlet.java:125: > >> UriStatus urlstatus, GadgetContext context, RenderingResults results) >> > throws > >> IOException { >> I'm not opposed, but do cast a somewhat suspicious eye on a catch-all >> postprocessing method that has a kitchen sink of arguments passed to >> > it :) I'm > >> wondering if we can make the types of customization more precise, to >> > encourage > >> reuse of common code. >> > > Do you have any examples (even if abstract) of the types of processing >> > desired? > > What's been moved into this method is fairly generic stuff: cache >> > handling, > >> error handling, redirect handling. Do you want to customize each such >> subroutine? Add arbitrary content manipulation @ the end of this whole >> > block? > > > > http://codereview.appspot.com/1665054/show >
