Marc,
As simplicity and beauty are so personal, I have little interest in
discussing these aspects further. I can only say that I'm not convinced by
the current PI and don't want to be accountable for it as is.
It seems that the best I can do is to write an alternative API and share it
with the EG with hope that differences will be more obvious and compelling.
Best regards,
Jerome
> -----Message d'origine-----
> De : Marc.Hadley_at_Sun.COM [mailto:Marc.Hadley_at_Sun.COM]
> Envoyé : jeudi 12 avril 2007 19:44
> À : dev_at_jsr311.dev.java.net
> Objet : Re: Redirection and creation <was> Re: Container Independence
>
> 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.
>
>
>