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