Paul Sandoz wrote:
> Hi Marc,
>
> So far the @*Param concept has been associated with the HTTP meta-data
> and not that of the entity so it might create some confusion (like you
> highlighted when overloading @QueryParam for form parameters).
>
> What happens if the developer specified the following:
>
> @POST @ConsumeMime("application/x-www-form-urlencoded")
> public Foo update(@QueryParam("name") String name, String formData)
>
> ?
>
>
> My ideal preference would be for a way to unify the processing of the
> media types "application/x-www-form-urlencoded" and
> "multipart/form-data"
I think we should explore this idea further for complex cases, but, I
still think we need an "ease-of-use" @*Param annotation. I know we all
have found a simple way to get parameters very useful when writing
Servlets the same should be available for JAX-RS.
[1] using a Java bean that is the entity, for
> example:
>
> // The Form interface is a marker for message body readers/writers
> public MyForm implements Form {
> public String name;
>
> public InputStream uploadedFile.
> }
>
We don't need "marker" interfaces anymore. We have annotations :)
> and allow for:
>
> @POST @ConsumeMime({"application/x-www-form-urlencoded",
> "multipart/form-data"})
> public Foo update(MyForm form)
>
>
> From this we could consider what it means to specify unwrapped form
> parameters in a way that does not clash with the concept of the entity
> parameter already specified.
>
Instead of a form specific approach, why not expand this to all
injection types? i.e.
@Mapped
public class MyBean {
private @HeaderParam("foo") int foo;
public void setSessionId(@CookieParam("sessionid") int sessionId) {...}
private @Param("file") InputStream file;
}
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com