Paul Sandoz wrote:
> Marc Hadley wrote:
>> What Bill suggests would require expanding the targets of the @*Param
>> annotations. They are currently only allowed on parameters. If we did
>> that we could support something like:
>>
>> @Path("foo")
>> @ConsumeMime("application/x-www-form-urlencoded")
>> public class Foo {
>>
>> @FormParam("name") String name;
>> @FormParam("rank") String rank;
>> @FormParam("serial") int serial;
>>
>> @POST
>> public void register() {
>> // do something with name, rank, serial
>> }
>> }
>>
>> Essentially the resource class is also the form bean suggested by Paul.
>>
>
> I was not suggesting the resource class becomes a bean i was suggesting
> a separate bean be used for the form data, like the following:
>
And I'm saying its not much of a stretch to use it beyond form data.
> 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 it would be best to get a good pluggable design for processing
> forms first, then consider whether it is worthwhile to unwrap the fields
> as parameters of the HTTP method or the inverse to consider a bean that
> acts the same as method parameters. Those bring along a whole set of
> other problems where as the use of a Form bean is isolated to the
> particular problem of forms themselves.
>
Please explain why you think opening up injection beyond Form classes
brings in a whole set of other problems? The only problem I see is that
it just doesn't work with the Provider/MessageBodyReader paradigm. But,
who cares? So its built in instead of using the messageBody
semantics...I'd rather have a beautiful user API than a beautifully
designed implementation.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com