Can you switch this back to allow @FormParam to be allowed on
fields/setter methods?
1) To be consistent with other *Params. If the user chooses to have a
bad design then that is their problem. I'm not too fond of defensive
constraints to protect users from themselves.
2) Because some of us would like to have a form class that allows us to
reuse @FormParam. i.e.:
@Form
public class MyForm {
@FormParam("blah") String blah;
}
@POST
public void post(MyForm form);
We now have to create a new annotation that does exactly the same thing.
FYI, Resteasy users have already asked for this feature.
Marc Hadley wrote:
> After discussing this with Paul we agree with your original suggestion
> and propose to restrict @FormParam usage to resource method parameters.
> @FormParam is different to the other @*Param in that it requires the
> entity body to be consumed so really it should be a peer of the entity
> parameter and not available elsewhere.
>
> Marc.
>
> On Jul 16, 2008, at 3:18 PM, Stephan Koops wrote:
>
>> Hi Marc,
>>
>> Marc Hadley schrieb:
>>> On Jul 16, 2008, at 6:53 AM, Stephan Koops wrote:
>>>> the read of an entity is only allowed for (sub) resource methods,
>>>> because the entity should only be processed there. I think it is
>>>> useful to think about to do the same with @FormParam, so that you
>>>> can not inject it into resource class fields and bean setters, if
>>>> the path is not fully parsed.
>>>> Perhaps there are good arguments against this. What do you think?
>>> A slightly different suggestion: if an @FormParam is encountered
>>> before the resource method is called then any entity parameter MUST
>>> be of type MultivaluedMap<String, String>.
>>>
>>> That way an implementation can consume the request entity as soon as
>>> the first @FormParam is encountered and we don't restrict the use of
>>> @FormParam.
>> Also a solution. IMO not the best for design reasons, but the
>> technical problems are resolved. And it's easy to use.
>>
>> Best regards
>> Stephan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com