On Fri, 2008-11-14 at 14:06 +0100, Paul Sandoz wrote:
> On Nov 14, 2008, at 12:55 PM, Martin Grotzke wrote:
>
> > Hi Paul,
> >
> > I'm just having a look at this, AFAICS there are two issues:
> >
> > 1) The mapping of the jersey Parameter to the WADL Param (in
> > WadlGeneratorImpl.createParam).
> >
> > 2) The mapping of the jersey Parameter.Source to param annotations in
> > ResourceDocAccessor.ParameterAnnotationMapping
> >
> > Regarding 1) I wonder how to map a param like FormParam or CookieParam
> > to a WADL param, as WADL defines plain, query, matrix, header and
> > template ([1]). Do you have a clue regarding this, or should I ask
> > this
> > on the wadl mailing list?
> >
>
> I think the WADL mailing list would be better in this respect.
After reading the WADL spec again I realized that the form param has to
be "translated" to a param child element of the (request) representation
element(instead of the request element), with type "query". The WADL
spec on the usage of the query param element with representation as
parent element:
"Specifies a component of the representation as a name value pair
formatted according to the rules of the media type. Typically used with
media type 'application/x-www-formurlencoded' or
'multipart/form-data'." ([1])
An open issue still is the CookieParam, I'll ask this on the WASL
mailing list.
>
>
> > Regarding 2) I noticed that Parameter.Source does not define FORM.
> > AFAICS the FormParam is mapped to the UNKNOWN source in this case. Is
> > this correct and intended? In this case I would also create such a
> > mapping.
> >
>
> Part of the issue is that FormParam is not really a param in the sense
> of the other ones as it is really associated with the request or
> response entity.
I'd say this is not entirely true. Perhaps this is a wording issue with
"request entity", as the request entity in the jersey/jax-rs sense
mostly is represented by a java object. But in terms of HTTP a form
param indeed is a part of the request body for a PUT/POST request.
Therefore the source of a parameter annotated with @FormParam indeed is
the request entity. Now I wonder what's the semantics of
Parameter.Source (and if the FormParam should have some
representation/mapping within that).
Cheers,
Martin
[1] Table 1 on p. 14 in
https://wadl.dev.java.net/wadl20061109.pdf
> What i think WADL would require in this respect is a
> way to describe a form representation.
>
>
>
>
> > As we have the mapping of Param annotation classes to the
> > Parameter.Source equivalent both in the IntrospectionModeller and the
> > ResourceDocAccessor.ParameterAnnotationMapping, I think that it's
> > worth
> > creating a single mapping enum and use it in both cases. Or just make
> > the IntrospectionModeller.ANOT_HELPER_MAP public.
> > The latter sounds like a hack, the former needs some thoughts where to
> > put this mapping, so I'd go for the former solution.
> > And perhaps it would be nice to also define the WADL param style in
> > this
> > mapping...
> >
> > What do you think?
> >
>
> I will defer to your superior knowledge in this area :-) but i think
> we should wait for the WADLing experts feedback as there may be better
> ways to manage forms.
>
> Paul.
>
>
> > Cheers,
> > Martin
> >
> >
> > [1] https://wadl.dev.java.net/wadl20061109.xsd
> >
> >
> > On Thu, 2008-11-13 at 17:50 +0100, Paul Sandoz wrote:
> >> Hi Luigi,
> >>
> >> Thanks for reporting this. Could you log an issue?
> >>
> >> Paul.
> >>
> >> On Nov 13, 2008, at 5:49 PM, Quattrocchi Luigi wrote:
> >>
> >>> Hi,
> >>> I'm using ver. 1.0 of Jersey and I've noticed that in the
> >>> automatically generated WADL the style attribute is missing for
> >>> parameters annotated with @FormParam. Actually, according to the
> >>> WADL schema, such attribute should be present (<xs:attribute
> >>> name="style" type="tns:ParamStyle" use="required"/>). This can be a
> >>> problem using some tools (e.g. soapUI ver. 2.5b2) that need to read
> >>> the WADL.
> >>> Kind regards,
> >>>
> >>> Luigi
> >>>
> >>>
> >>> CONFIDENTIALITY NOTICE
> >>>
> >>> This message and its attachments are addressed solely to the persons
> >>> above and may contain confidential information. If you have received
> >>> the message in error, be informed that any use of the content hereof
> >>> is prohibited. Please return it immediately to the sender and delete
> >>> the message. Should you have any questions, please contact us by
> >>> replying to webmaster_at_telecomitalia.it.
> >>>
> >>> Thank you
> >>>
> >>> www.telecomitalia.it
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> >>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> >> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >
> > --
> > Martin Grotzke
> > http://www.javakaffee.de/blog/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
--
Martin Grotzke
http://www.javakaffee.de/blog/