[bv-dev] Nested message parameters and EL expressions

[Gunnar Morling]

2013/11/18 Hardy Ferentschik <hardy at hibernate.org>

> hi,
>
> not the sure whether this is so easy. I think the case of nested
> parameters is not properly covered in the spec atm.
> A few comments inline
>
> On 18 Jan 2013, at 16:31, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> > I think the algorithm should cover for that case, even if we didn't plan
> for it.
> >
> > In steps 1 - 4 only message parameters are resolved (against the
> resource bundles and then in step 4 against constraint attributes). Only in
> step 5 the EL evaluation is performed. There is no loop back to parameter
> resolution after EL interpolation.
>
> I think that is basically missing. I am not sure whether it is a good idea
> to perform message parameter resolution within an EL expression.
> I’d rather loop back after EL evaluation and perform another message
> parameter resolution.
>

Why would you do that though? Seems like the current algorithm covers that
case already? Wouldn't it get more complicated by doing another loop?


>
> > So considering the following example:
> >
> >     @ThresholdMax(value=10, messageThreshold=50,
> message="${validatedValue > {messageThreshold} ? '{muchTooLarge.message}' :
> '{aBitTooLarge.message}'}")
> >     int myInt = ...;
> >
> > Then I'd say algorithm should transform the message like this:
> >
> > After step 3 (resource bundle replacements): "${validatedValue >
> {messageThreshold} ? 'Viel zu groß' : 'Zu groß’}"
>
> there is no need for  {messageThreshold} in the comparison. The value for
> messageTreshold is already bound to the EL context. '${validatedValue >
> messageThreshold’
> is already sufficient.
>

Yes, that's right indeed. I was under the assumption that constraint
parameters are not available for EL interpolation but as you say they are.
So the scenario really is using messages from the resource bundle.


> Also I rather just let the EL return {muchTooLarge.message} resp
> {aBitTooLarge.message} and then loop back, instead to do replacement with
> the expression first.
>

What is the advantage of that? I fear changes to the algorithm might cause
compatibility issues and it seems to work also without any changes.


>
>
> —Hardy
>
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20131118/f3fe8a31/attachment.html