<div dir="ltr">2013/11/18 Hardy Ferentschik <span dir="ltr"><<a href="mailto:hardy@hibernate.org" target="_blank">hardy@hibernate.org</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> not the sure whether this is so easy. I think the case of nested parameters is not properly covered in the spec atm.<br>
> A few comments inline<br>
><br>
> On 18 Jan 2013, at 16:31, Gunnar Morling <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>> wrote:<br>
><br>
> > I think the algorithm should cover for that case, even if we didn't plan for it.<br>
> ><br>
> > 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.<br>
><br>
> 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.<br>
> I’d rather loop back after EL evaluation and perform another message parameter resolution.<br>
><br>
> Why would you do that though? Seems like the current algorithm covers that case already?<br>
<br>
</div>Provided you imply that this type of nested case is allowed.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> Wouldn't it get more complicated by doing another loop?<br>
<br>
</div>I think it would be the more natural way of doing it and also inline with how the current algorithm works.<br></blockquote><div><br></div><div>I'm wondering whether there are cases where you actually want to refer to a replaced parameter from within your EL expression.</div>
<div><br></div><div>Say you want to make the threshold value from the example <span style="font-family:arial,sans-serif;font-size:13px">${validatedValue > {threshold} ? '{muchTooLarge.message}'</span> 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.</div>
<div><br></div><div>Also from a performance perspective I'd rather not add further passes to the interpolation algorithm if not required. </div><div><div class="im"><br>
> > After step 3 (resource bundle replacements): "${validatedValue > {messageThreshold} ? 'Viel zu groß' : 'Zu groß’}"<br>
><br>
> there is no need for {messageThreshold} in the comparison. The value for messageTreshold is already bound to the EL context. '${validatedValue > messageThreshold’<br>
> is already sufficient.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> What is the advantage of that?<br>
<br>
</div>> I am thinking of something like this: ${1 > 0 ? ‘{' : ‘}’}<br>> 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<br>
> this.</div><div><br></div><div>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.</div>
<div><br>
<div class=""><div class="h5"><br>
—Hardy<br>
<br>
<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>
</div></div></div></div><br></div></div>