[jsr-314-open] Fwd: [426-BeanValidation] Default Enablement Change

Pete Muir pmuir at REDHAT.COM
Sat Mar 7 06:42:00 EST 2009



Begin forwarded message:

> From: Emmanuel Bernard <emmanuel.bernard at jboss.com>
> Date: 6 March 2009 21:03:51 GMT
> To: Ed Burns <Ed.Burns at Sun.COM>
> Cc: Pete Muir <pmuir at redhat.com>, Dan Allen <dan.j.allen at gmail.com>
> Subject: Re: [426-BeanValidation] Default Enablement Change
>
> Hi Ed,
> What are you reasons for not allowing this "auto" mode by default
> (both for the default validator and the validate empty fields?
>
> We initially had something like you proposed but we decided to align
> with JPA to get a better cleaner alignment of the Java programmatic
> model at large (SE and EE). I can understand your uneasiness (I was
> a bit initially too) but I think it's for the greater of JSF and the
> platform, esp wrt ease of use.
> We are at an interesting tipping point. BV is not in applications
> yet so we can define the best defaults for the present and the
> future. It will be too late to move forward after that. Remember, if
> BV is not in the classpath, nothing changes. If someone wants to
> force the old legacy approach, it's two properties away.
>
> Emmanuel
>
> On  Mar 6, 2009, at 15:47, Dan Allen wrote:
>>
>>
>> ---------- Forwarded message ----------
>> From: Ed Burns <Ed.Burns at sun.com>
>> Date: Fri, Mar 6, 2009 at 3:41 PM
>> Subject: [426-BeanValidation] Default Enablement Change
>> To: JSR-314-OPEN at jcp.org
>>
>>
>> Change 1
>>
>>
>> When sitting down to move the content out of Appendix C and into the
>> spec proper, I came across this statement, currently in setion
>> 2.3.2 of
>> Appendix C.
>>
>>  If Beans Validation is present in the environment (i.e., the
>>  javax.validation.Validation class is available on the classpath),
>> the
>>  validator with javax.faces.Bean is considered the default
>> validator if
>>  no default validators are defined.
>>
>> I would like to remove this statement and replace it with.
>>
>>  If running in a container that supports Beans Validation, adding the
>>  validator with id "javax.faces.Bean" to the default-validator
>> section
>>  enables Beans Validation integration.
>>
>> Change 2
>>
>> In section 11.1.3, where we declare the context-params and how to
>> handle
>> them, this text appears:
>>
>> * javax.faces.VALIDATE_EMPTY_FIELDS -- If this param is set, and
>> calling
>>  toLowerCase().equals("true") on a String representation of its value
>>  returns true, all submitted fields will be validated. This is
>>  necessary to allow the model validator to decide whether null or
>> empty
>>  values are allowable in the current application. If the value is
>>  "false", null or empty values will not be passed to the
>> validators. If
>>  the value is the string "auto", the runtime must check if JSR-303
>>  Beans Validation is present in the current environment. If so, the
>>  runtime must proceed as if the value "true" had been specified. If
>>  JSR-303 Beans Validation is not present in the current environment,
>>  the runtime most proceed as if the value "false" had been specified.
>>
>> I would like to add the following after the last sentance above.
>> If the
>> param is not set, the system must behave as if the param was set with
>> the value "false"
>>
>> ACTION: please reply my 0900 EST Monday 20090309.
>>
>> Thanks,
>>
>> Ed
>>
>> --
>> | ed.burns at sun.com  | office: 408 884 9519 OR x31640
>> | homepage:         | http://ridingthecrest.com/
>>
>>
>>
>> --
>> Dan Allen
>> Senior Software Engineer, Red Hat | Author of Seam in Action
>>
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>>
>> NOTE: While I make a strong effort to keep up with my email on a
>> daily
>> basis, personal or other work matters can sometimes keep me away
>> from my email. If you contact me, but don't hear back for more than
>> a week,
>> it is very likely that I am excessively backlogged or the message was
>> caught in the spam filters.  Please don't hesitate to resend a
>> message if
>> you feel that it did not reach my attention.
>

--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090307/cdfb1ba0/attachment.html 


More information about the jsr-314-open-mirror mailing list