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(a)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