[bv-dev] Nested message parameters and EL expressions

[Gunnar Morling]

2013/11/18 Hardy Ferentschik <hardy at 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 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.
>

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 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/20131119/1c7a854e/attachment.html