Hi Paul,
Thank you so much for your detailed explanation. I agree with your all
explanations.
Returning error for empty strings and non-digit string is making useless for
number fields unfortunately. Now I will change these fields as you stated.
I also agreed with you improving error returning usage in terms of user
perspective.
Maybe spec of the JSR-311 can be revised again to use bean validation
framework. I read that There is not intersection parts between JSR-303 and
JSR-311. However now I believe that especially after support of form beans,
support of bean validation natively by Jersey or JSR-311 spec can be great.
:)
Thanks
Paul Sandoz wrote:
>
>
> On Dec 17, 2009, at 9:02 AM, Cemo Koc wrote:
>
>>
>> Hi Paul,
>>
>> For such a bean,
>>
>> public class AccountBean {
>>
>> @FormParam("acc.type")
>> private Integer type;
>>
>> }
>>
>>
>> I believe that Jersey should never return an error code 400. Because
>> it is
>> restricting the usage of Jersey. In my opinion:
>>
>> 1) In case sending a post value like this "acc.type=", it should
>> inject
>> null to Integer
>>
>>
>> 2) In case sending a post value like this "acc.type=a1b2", it
>> should inject
>> null to Integer
>>
>
> How do we differentiate between the above two cases and the additional
> case of an absent (optional) parameter?
>
> There are four general cases for declaration of a parameter:
>
> 1) parameter is absent;
>
> 2) "acc.type"
>
> 3) "acc.type="
>
> 4) "acc.type=12"
>
> plus an additional case for 2, 3 & 4 for multiple declarations of the
> same parameter.
>
> In my previous email I proposed that 2 and 3 should be considered
> equivalent.
>
>
> Then we have the two following cases:
>
> 1) Defining what is a required parameter, which has been brought up
> before; and
>
> 2) Defining the behavior for an invalid parameter, when an instance
> of a type cannot be constructed from the String value.
>
>
> For 1) it has been proposed to support something like @Required.
>
> For 2), the additional case you raised, it will obviously not be
> possible for you to validate the integer value itself (unless you use
> a String rather than Integer).
>
> We could support an additional annotation like @NullOnInvalid.
>
> Or we could support a wrapper class e.g.:
>
> @FormParam Wrapper<Integer> i;
>
> where "i" will be non-null if the parameter is present, i.get will
> thrown an exception if the value is invalid and will return null if
> the parameter has no value.
>
>
>> I think that It might call constructor of Integer with an empty
>> string.
>
> Yes.
>
>
>> And
>> then if it raises an exception, it should simply inject null value.
>
> I think there is more to this area to take into consideration as i
> have suggested above.
>
>
>> But in
>> our case it is returning with 400. This is restricting our validation.
>
> Agreed.
>
>
>>
>> In Jersey Java Doc this part of FormParam is not very clear.
>>
>
> Agreed it is defined in the spec, but should also be in the JavaDoc:
>
> https://jsr311.dev.java.net/nonav/releases/1.1/spec/
> spec3.html#x3-220003.2
>
>
>> And what If I want to use a custom validation logic such as JSR-303
>> in this
>> fields, what is your proposal?
>>
>
> Currently, i think the only way is to resort to using String. But i
> would like to implement an appropriate solution to improve this area.
>
> Paul.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
--
View this message in context: http://n2.nabble.com/Formparam-for-Non-String-Fields-tp4177365p4180453.html
Sent from the Jersey mailing list archive at Nabble.com.