[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