[bv-dev] Nested message parameters and EL expressions

Gunnar Morling gunnar at hibernate.org
Mon Nov 18 14:37:18 EST 2013


Created https://hibernate.atlassian.net/browse/BVAL-469

--Gunnar



2013/11/18 Emmanuel Bernard <emmanuel at hibernate.org>

> 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 at hibernate.org>
> >
> > > 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 at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >
> > > _______________________________________________
> > > beanvalidation-dev mailing list
> > > beanvalidation-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >
>
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> 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/20131118/4be38fd2/attachment-0001.html 


More information about the beanvalidation-dev mailing list