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

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

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

Right. I don't see where the spec prohibits it though. So if the case can be supported in a sensible way without changing the algorithm (e.g. by providing an example) I would personally prefer that. That way also impls could support this kind of nesting without requiring a spec update.
 

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

I'm wondering whether there are cases where you actually want to refer to a replaced parameter from within your EL expression.

Say you want to make the threshold value from the example ${validatedValue > {threshold} ? '{muchTooLarge.message}' configurable by not retrieving it from the annotation but by putting a value under the "threshold" key to the resource bundle. This would only work when all parameter replacements are finished before doing the EL interpolation.

Also from a performance perspective I'd rather not add further passes to the interpolation algorithm if not required. 

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

That's an interesting case. Wouldn't the inner curly braces have to be escaped: ${1 > 0 ? ‘\{' : ‘\}’}? Btw. as it seems this example doesn't work in HV either way, I've created HV-834 for this.


—Hardy




_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev