Sounds like a plan, will post the revised version.
Thx,
- Henry
On 2010/07/22 23:42:16, fargo wrote:
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, <mailto:[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
>
http://codereview.appspot.com/1665054/show
