Hi Paul,
The advantage is to allow one to specify what each parameter gets. This is
especially for method taking multiple parameters:
public void put(@Input String value, @Variable String customerId){
...
}
Note that put() method doesn't need to be annotated itself because its name
and the presence of @Input ensure it is correctly detected. The @Variable
annotation would also use the parameter name by default as the name of the
URI variable to extract ("customerId" here).
Best regards,
Jerome
> -----Message d'origine-----
> De : Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Envoyé : lundi 21 mai 2007 14:51
> À : dev_at_jsr311.dev.java.net
> Objet : Re: Consume/Produce and Input/Output
>
> Hi Jerome,
>
> What are the advantages to allowing one to annotate a method
> parameter?
>
> Paul.
>
> Jerome Louvel wrote:
> > Hi Paul,
> >
> > I think that the answer to those questions is unique. If
> people prefer some
> > more precise terms, here are some alternatives to Input/Output:
> > - InputEntity / OutputEntity
> > - InputContent / OutputContent
> > - RequestEntity / ResponseEntity
> > - RequestContent / ResponseContent
> >
> > Now, ConsumeContent/ProduceContent are nice names too, but
> they have a
> > disadvantage: they can't be used as parameter annotations because it
> > wouldn't make sense:
> >
> > public void put(@ConsumeContent String value){
> > ...
> > }
> >
> > while @Input (or similar alternatives) is more flexible and
> can annotate
> > either the class, the method or the parameter:
> >
> > public void put(@Input String value){
> > ...
> > }
> >
> > Best regards,
> > Jerome
> >
> >> -----Message d'origine-----
> >> De : Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> >> Envoyé : vendredi 18 mai 2007 14:34
> >> À : dev_at_jsr311.dev.java.net
> >> Objet : Consume/Produce and Input/Output
> >>
> >> Hi Jerome,
> >>
> >> I think there are two separate issues:
> >>
> >> 1) The more general annotations for the support of additional
> >> content for negotiation; and
> >>
> >> 2) The placement of those annotations on
> classes/methods/parameters.
> >>
> >>
> >> 1)
> >> ---
> >>
> >> I don't detect any general disagreement over 1, although i
> >> would like to
> >> hear more opinions on this by others.
> >>
> >> IMHO the Input/Output names are too vague. I would prefer
> >> something more
> >> descriptive and accurate, for example
> >> ConsumeContent/ProduceContent. The
> >> use of consume/produce also tends to read very nicely when
> >> expressed in
> >> sentences (at least in English!) about a resource or a method
> >> of a resource.
> >>
> >> I guess we could argue over Input vs. Consume till entropy
> >> death of the
> >> universe, life is too short :-) the only strong opinion i
> >> have is that
> >> the annotation names clearly reflect what they are
> specified to do so
> >> that developers can make intuitive guesses.
> >>
> >>
> >> 2)
> >> ---
> >>
> >> IIRC Marc has discussed this before in other email threads.
> >> But it has
> >> been a long time. Perhaps you could refresh our memories and
> >> summarize
> >> the differences/commonalities/pros/cons of the two positioning
> >> approaches from your perspective?
> >>
> >> Paul.
> >>
> >> --
> >> | ? + ? = 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>