struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukasz Lenart <lukaszlen...@apache.org>
Subject Re: parse or not
Date Tue, 19 Mar 2013 08:36:38 GMT
2013/3/18 Matt Raible <matt@raibledesigns.com>:
> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message