[bv-dev] BVAL-192 and BVAL-223

Emmanuel Bernard emmanuel at hibernate.org
Fri Jan 18 13:09:09 EST 2013


I did most of my remarks in the pull request but here are some specific
to your questions.

On Thu 2013-01-17 16:48, Hardy Ferentschik wrote:
> * Is the benefit offered by this solution big enough to introduce a dependency to another API/JSR?

I think so, we have had many features tangentially related to improving
method interpolation and this addition will solve most if not all of
them in a very elegant way.

> * I am proposing to bind the validated value to the string literal 'validatedValue'. Is this a good name? 'value' would be shorter, but would conflict with
>  the default annotation parameter name

validatedValue has my preference too.

> * I am proposing to bind String#format to the literal 'str:format'. Does this prefix sound ok, or should it be 'string:format'. 

Small preference to string:format (for readability) but I won't fight.

> * Is there a need to specify more functions which need to be available in the EL context (on top of String#format)?

I'm tempted to say probably in the future. We should go for a simple
version now and think about more binding or even customized bindings in
a future rev of the spec.

> * Using the ${expression} syntax causes a backward compatibility issue with BV 1.0 where '$' was used as literal, e.g. ${amount} would be $10 in BV 1.0
>   whereas now it would be just 10. Maybe '#' would be a better marker for EL expressions or to be 100% correct a configuration flag would be needed.

It seems $ is the standard so I'm ok to create some transitional
frictions for a better future. We did not make horrible mistakes in 1.0
so we have some good will to burn ;)

> * Last but not least, how should be handle invalid EL expressions or expressions which reference non existent properties. For the user it might be best
>  to catch any EL based exception and just return the un interpolated expression (the actual impl could log a warning). If we propagate exceptions might have
>  to deal with exception based on poor message/expression design.
> 
> Looking forward to get some feedback,
> Hardy
> 
> 
> [1] https://hibernate.onjira.com/browse/BVAL-192
> [2] https://hibernate.onjira.com/browse/BVAL-223
> [3] https://github.com/beanvalidation/beanvalidation-spec/pull/41
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


More information about the beanvalidation-dev mailing list