On Feb 15, 2008, at 12:08 PM, Bill Burke wrote:
>
>> This fits nicely into the model we already have for entities
>> without any confusion over the overloading of @QueryParam and can
>> work with both form media types and requires no changes or
>> additions to the current @*Param annotations.
>
> THe spec isn't finished, so why avoid changes/additions? Again, we
> need a simple way to get at parameters. query and form parameters
> are both common ways of passing parameter information, so we need a
> simple way of doing it regardless if we have a more complex form of
> injection.
>
I think the bean approach is actually pretty simple and as Paul points
out it maintains the current abstraction whereby a request body maps
to one method parameter. Compare:
@Path("foo")
@ConsumeMime("application/x-www-form-urlencoded")
public class Foo {
@POST
public void register(@FormParam("name") String name,
@FormParam("serial") int serial,
@FormParam("rank") String rank) {
// do something with name, rank, serial
}
}
vs
@Path("foo")
@ConsumeMime("application/x-www-form-urlencoded")
public class Foo {
@POST
public void register(FormData data) {
// do something with form data
}
public static class FormData {
String name,
int serial,
String rank }
}
The main difference is that the former requires lots of @FormParam
annotations while the latter requires a new class that encapsulates
the form data.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.