From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Thu, 12 Apr 2007 14:36:47 -0400

On Apr 12, 2007, at 2:05 PM, Jerome Louvel wrote:
>
> 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.
>
Fair enough, but before you do that take a look at the proposal I
just sent out on the "Mapping POJOs" thread. I think that could go
some way to reconciling our differences in that area at least.

Marc.

>
>> -----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.
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>

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