<div dir="ltr">Created <a href="https://hibernate.atlassian.net/browse/BVAL-469">https://hibernate.atlassian.net/browse/BVAL-469</a><div><br></div><div>--Gunnar</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2013/11/18 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That makes sense.<br>
Can you open a BVAL issue to clarify the possibility in the spec and add<br>
the relevent bits of this conversation?<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon 2013-11-18 16:31, Gunnar Morling wrote:<br>
> I think the algorithm should cover for that case, even if we didn't plan<br>
> for it.<br>
><br>
> In steps 1 - 4 only message parameters are resolved (against the resource<br>
> bundles and then in step 4 against constraint attributes). Only in step 5<br>
> the EL evaluation is performed. There is no loop back to parameter<br>
> resolution after EL interpolation.<br>
><br>
> So considering the following example:<br>
><br>
> @ThresholdMax(value=10, messageThreshold=50, message="${validatedValue<br>
> > {messageThreshold} ? '{muchTooLarge.message}' :<br>
> '{aBitTooLarge.message}'}")<br>
> int myInt = ...;<br>
><br>
> Then I'd say algorithm should transform the message like this:<br>
><br>
> After step 3 (resource bundle replacements): "${validatedValue ><br>
> {messageThreshold} ? 'Viel zu groß' : 'Zu groß'}"<br>
> After step 4 (resolution of constraint attributes): "${validatedValue > 50<br>
> ? 'Viel zu groß' : 'Zu groß'}"<br>
> After step 5 (EL evaluation): "Viel zu groß" or "Zu groß", depending on the<br>
> threshold value<br>
><br>
> --Gunnar<br>
><br>
><br>
><br>
><br>
> 2013/11/18 Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>><br>
><br>
> > Depending how the spec is written it might already be too late but I<br>
> > would definitely like something like that to happen.<br>
> ><br>
> > We just need to be careful, which interpolation should happen first or<br>
> > if we want to do them in a loop until the system rests.<br>
> ><br>
> > On Mon 2013-11-18 9:32, Gunnar Morling wrote:<br>
> > > Hi,<br>
> > ><br>
> > > I came across an interesting case in the HV user forum [1], where a user<br>
> > is<br>
> > > essentially nesting messages parameters within an EL expression:<br>
> > ><br>
> > > ${validatedValue > someValue ? '{x.y.z.message}' : '{x.y.w.message}'}<br>
> > ><br>
> > > The expectation is that at first the two message parameters are resolved<br>
> > > and then based on the conditional expression the outer EL expression<br>
> > either<br>
> > > resolves to one message or the other.<br>
> > ><br>
> > > This is currently not supported in HV, but reading the interpolation<br>
> > > algorithm in the spec [2] I can't find anything indicating that this case<br>
> > > would prohibited. On the other hand I'm not sure whether we intentionally<br>
> > > meant to support it (at least it never occurred to me); if so, I think we<br>
> > > should provide an example for this in the spec.<br>
> > ><br>
> > > The use case seems valid to me, also for cases where one wants to refer<br>
> > to<br>
> > > constraint attributes in conditional logic. Any thoughts?<br>
> > ><br>
> > > --Gunnar<br>
> > ><br>
> > > [1] <a href="https://forum.hibernate.org/viewtopic.php?f=9&t=1029782" target="_blank">https://forum.hibernate.org/viewtopic.php?f=9&t=1029782</a><br>
> > > [2] <a href="http://beanvalidation.org/1.1/spec/#default-resolution-algorithm" target="_blank">http://beanvalidation.org/1.1/spec/#default-resolution-algorithm</a><br>
> ><br>
> > > _______________________________________________<br>
> > > beanvalidation-dev mailing list<br>
> > > <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> > > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> ><br>
> > _______________________________________________<br>
> > beanvalidation-dev mailing list<br>
> > <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> ><br>
<br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</div></div></blockquote></div><br></div>