{messageThreshold} ? '{muchTooLarge.message}' :

Depending how the spec is written it might already be too late but I would definitely like something like that to happen. We just need to be careful, which interpolation should happen first or if we want to do them in a loop until the system rests. On Mon 2013-11-18 9:32, Gunnar Morling wrote: > Hi, > > I came across an interesting case in the HV user forum [1], where a user is > essentially nesting messages parameters within an EL expression: > > ${validatedValue > someValue ? '{x.y.z.message}' : '{x.y.w.message}'} > > The expectation is that at first the two message parameters are resolved > and then based on the conditional expression the outer EL expression either > resolves to one message or the other. > > This is currently not supported in HV, but reading the interpolation > algorithm in the spec [2] I can't find anything indicating that this case > would prohibited. On the other hand I'm not sure whether we intentionally > meant to support it (at least it never occurred to me); if so, I think we > should provide an example for this in the spec. > > The use case seems valid to me, also for cases where one wants to refer to > constraint attributes in conditional logic. Any thoughts? > > --Gunnar > > [1] https://forum.hibernate.org/viewtopic.php?f=9&t=1029782 > [2] http://beanvalidation.org/1.1/spec/#default-resolution-algorithm > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

That makes sense. Can you open a BVAL issue to clarify the possibility in the spec and add the relevent bits of this conversation? On Mon 2013-11-18 16:31, Gunnar Morling 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. > > 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ß'}" > After step 4 (resolution of constraint attributes): "${validatedValue > 50 > ? 'Viel zu groß' : 'Zu groß'}" > After step 5 (EL evaluation): "Viel zu groß" or "Zu groß", depending on the > threshold value > > --Gunnar > > > > > 2013/11/18 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > > > Depending how the spec is written it might already be too late but I > > would definitely like something like that to happen. > > > > We just need to be careful, which interpolation should happen first or > > if we want to do them in a loop until the system rests. > > > > On Mon 2013-11-18 9:32, Gunnar Morling wrote: > > > Hi, > > > > > > I came across an interesting case in the HV user forum [1], where a user > > is > > > essentially nesting messages parameters within an EL expression: > > > > > > ${validatedValue > someValue ? '{x.y.z.message}' : '{x.y.w.message}'} > > > > > > The expectation is that at first the two message parameters are resolved > > > and then based on the conditional expression the outer EL expression > > either > > > resolves to one message or the other. > > > > > > This is currently not supported in HV, but reading the interpolation > > > algorithm in the spec [2] I can't find anything indicating that this case > > > would prohibited. On the other hand I'm not sure whether we intentionally > > > meant to support it (at least it never occurred to me); if so, I think we > > > should provide an example for this in the spec. > > > > > > The use case seems valid to me, also for cases where one wants to refer > > to > > > constraint attributes in conditional logic. Any thoughts? > > > > > > --Gunnar > > > > > > [1] https://forum.hibernate.org/viewtopic.php?f=9&t=1029782 > > > [2] http://beanvalidation.org/1.1/spec/#default-resolution-algorithm > > > > > _______________________________________________ > > > beanvalidation-dev mailing list > > > beanvalidation-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > > _______________________________________________ > > beanvalidation-dev mailing list > > beanvalidation-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

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(a)hibernate.org&gt; 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.

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

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.

—Hardy _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

> 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&gt; 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.

{threshold} ? '{muchTooLarge.message}' configurable by not retrieving it

> After step 3 (resource bundle replacements): "${validatedValue >

there is no need for {messageThreshold} in the comparison. The value for

is already sufficient. Yes, that's right indeed. I was under the assumption that constraint

Also I rather just let the EL return {muchTooLarge.message} resp

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 {'

this.