2013/3/18 Matt Raible <[email protected]>:
> I believe the ${} is enough of an indicator that it's an expression. So I
> guess that's +1 for parsing.
I think I have to explain it a bit more:
before there was a dedicated param called "parse" to enable parsing or
not the validator's params, like below:
@IntRangeFieldValidator(message = "Default message", min =
"${minValue}", max = "${maxValue}" parse="true")
There were few advantages:
- security, user had to enable it on purpose
- the same params could be used to specify static values (min = "1",
max = "10") and dynamic values, parse param has switched the mode
- efficiency, there was no need to parse values if constants were used,
With new (better ;-) validators in place, I have removed the parse
param as this was redundant to dedicated params to specify
expressions, like below:
@IntRangeFieldValidator(message = "Default message", minExpression =
"${minValue}", maxExpression = "${maxValue}")
Thus still have some advantages:
- security, user must use dedicated params to enable expressions
- efficiency, as user can mix constant and dynamic values
By reverting parse param back I thought about returning to how it was
previously - use the same param for static and dynamic value, thus
will simplify the Api (user will have to define just one value). There
can be some minor problems with mixing types of value.
By efficiency in both cases I mean not to call Ognl to parse static
value eg.: min = "1" will be evaluated as 1 but it will take a bit of
time ;-)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
