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.
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
>