2013/11/18 Hardy Ferentschik <hardy@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev