+1
Ryan-
On Aug 5, 2008, at 9:44 AM, Bill Burke wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>