[bv-dev] Nested message parameters and EL expressions

[Hardy Ferentschik]

> 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?

Provided you imply that this type of nested case is allowed. 

> Wouldn't it get more complicated by doing another loop?

I think it would be the more natural way of doing it and also inline with how the current algorithm works.

> > 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 am thinking of something like this: ${1 > 0 ? ‘{' : ‘}’}
Would your interpretation not imply that we make an attempt to resolve {' : ‘} as message parameter. I guess in most cases this might be harmless, but I have a bad feeling about
this. 

—Hardy