Jerome Louvel wrote:
> Hi Paul,
>
> I think we could go further we automatically finding what is the best
> representation among all acceptable ones, based on client preferences and
> without requiring the developer to do anything else beside exposing its
> available representations.
>
Could you describe what you have in mind in more detail?
For the cases where what is acceptable cannot be determined statically
via annotations are you proposing something similar to Restlet, which
IIUC has a two stage method calling process? (Call a method to get the
list of variants, then call the HTTP method with the selected variant.)
Assuming you are thinking along the lines of the Restlet design and that
i have understood things correctly... the developer still has to perform
an if/else on the selected variant to know which one has been selected
by the runtime, and would still have to return some actual content.
In fact returning null can signal a not acceptable response is required:
if (x.isAcceptable(..., ..., ...)) {
} else if x.isAcceptable(...)) {
} else { return null; }
so the runtime can still handle the error.
In this case there is no need for a two stage method call process (the
contract remains that specified by @HttpMethod), the flow of control is
the same for singleton and per-request life-cycles, the acceptable data
is not required to be grouped and produced dynamically in a specified
way, and the LOC are probably similar between the two approaches.
Paul.
> Best regards,
> Jerome
>
>> -----Message d'origine-----
>> De : Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
>> Envoyé : mardi 22 mai 2007 15:07
>> À : dev_at_jsr311.dev.java.net
>> Objet : Re: Issue 1: Adding additional conneg metadata to
>> @Produce/ConsumeXXX
>>
>> Marc Hadley wrote:
>>> On May 21, 2007, at 11:09 AM, Paul Sandoz wrote:
>>>
>>>> Marc Hadley wrote:
>>>>> On May 19, 2007, at 10:32 AM, Jerome Louvel wrote:
>>>>>>> I'm therefore not yet convinced that adding a
>> declarative language
>>>>>>> capability is that useful in practice. I think the above does
>>>>>>> illustrate a need for a "QValuedCommaSeparatedList"
>> type to aid in
>>>>>>> parsing of the Accept-XXX headers though.
>>>>>> Like you, I'm not sure yet about the practicality of
>> declaring those
>>>>>> metadata as annotations. However, I think that we should
>> protect the
>>>>>> resource code from client preferences considerations like
>>>>>> parsing/analyzing
>>>>>> the Accept* headers!
>>>>>>
>>>>> I think we can certainly help with the parsing as I suggested.
>>>> Another way of thinking about this is to have isAcceptable and
>>>> isNotAcceptable methods on say an 'AcceptableEvaluator' interface.
>>>>
>>> Interesting idea. Perhaps we could generalize the existing
>>> ProconditionEvaluator interface:
>>>
>>>
>> https://jsr311.dev.java.net/sketches/sketch3/javax/ws/rs/core/
>> PreconditionEvaluator.html
>>>
>>> Additional methods could be added to enable an application to
>>> dynamically check if the available languages, encodings and
>> charsets
>>> meet the clients preferences or not.
>>>
>> That would work.
>>
>> Thinking some more... for these cases it is possible to expose the
>> actually header values using HeaderParam with a List or Set that is
>> ordered according to the q parameter, since the runtime knows the
>> meaning of such headers.
>>
>> But i prefer method calling as i think it is more meaningful
>> and concise
>> in terms of the process (especially when multiple things might be
>> acceptable for a response):
>>
>> if (x.isAcceptable(..., ..., ...)) {
>> } else if x.isAcceptable(...)) {
>> } else { return Response.Builder.notAcceptable().build(); } *
>>
>> Paul.
>>
>> [*] Tis a small thing but for the returning of stuff we could
>> also allow
>> the return of:
>>
>> return Response.Builder.notAcceptable();
>>
>> and the runtime could call the build() method.
>>
>> --
>> | ? + ? = To question
>> ----------------\
>> Paul Sandoz
>> x38109
>> +33-4-76188109
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109