dev@jsr311.java.net

Re: Redirection and creation <was> Re: Container Independence

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Thu, 12 Apr 2007 13:44:25 -0400

On Apr 12, 2007, at 9:05 AM, Jerome Louvel wrote:
>
>>> ctx.redirectPermanent("/target/{orderId}";
>>> }
>>> }
>>
>> How are the two approaches above simpler than having just one
>> solution to solve the problem, namely the returning of a Java object
>> (as Marc has previously shown):
>>
>> return new PermanentRedirect("/target/{orderId}");
>
> Because with one Context class you can solve many other problems like
> setting the status code, the reason phrase, local forward. It's
> simpler than
> having to rely on:
> - HttpContext
> - HttpRequestContext
> - HttpResponseContext
> - WebResource
> - Created
> - HttpResponse
> - NotModified
> - TemporaryRedirect
>
> 1 class instead of 8 different types, without loosing features is
> compelling
> enough for me.
>
This line of reasoning worries me a bit - is one class with a hundred
methods simpler that ten classes with ten methods each ? Classes and
interface provide structure to an API and allow you to group related
things together. I'm not against consolidation per-se but I think
that lumping everything together into one class isn't necessarily
going to make for a simpler API.

E.g. currently HttpRequestContext has methods associated with a
request and HttpResponseContext has methods associated with a
response. Would merging those two classes into one make really things
simpler ? I'm not yet convinced that it would.

Similarly for HttpResponse and its subclasses. Each subclass is an
abstraction for a certain kind of response like a temporary redirect.
Each one exposes the properties that are required for that kind of
response and its easy to see from the subclass constructor what data
+metadata is required to issue a correct response of that kind. Using
a context type approach you either leave the developer on their own
to set the right set of properties or you add a method for each kind
of response that populates the individual properties accordingly. A
context-based approach also requires the developer to abandon the
normal return-value based approach for returning data and dive into
the low level API for a variety of common use cases which seems
unfortunate.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.