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
