Evildonald posted on Wednesday, July 22, 2009
Hi there,
This isn't *technically* a bug, but the code definitely doesn't work as advertised for one argument.
I was attempting to implement a CommonRules.RegexMatch rule which would fail validation if a certain word (eg. "foo") was contained in it. Regular expression can handle this with
(?!foo)
which will return with a null result for each character.
Here is the bug/problem: in CommonRules.RegExRuleArgs there is a parameter enum which is called "NullResultOptions" which has the options convert, true, false.
I would have
expected this to apply to the
result of the regular expression matching, so I could say, "if the result is null, return false", but this instead applies to the
value of the target. It does not apply to the
result at all!
What should change:
- NullResultOptions should be changed to NullValueOptions as it is clearly the wrong name.
- Could you implement an actual NullResultOption that would do what it's name says and will let you specify whether a match that is null will return True or False.
thanks
Dan
JoeFallon1 replied on Wednesday, July 22, 2009
FYI - I do not use the CommonRules at all.
I copied them to my own library a long time ago and then tweaked them to meet my requirements. I suggest that you do something similar for some or all of these rules - especially the regex rule. Rocky only included them in CSLA as sample rules for "simple cases" that can be re-used across BOs. The goal is for each user to develop their own library of rules to meet their own requirements.
Joe
tmg4340 replied on Wednesday, July 22, 2009
Additionally, I wouldn't expect the regular-expression common rules to stick around long-term. There have been several discussions surrounding the email-validation one, and I think that has led Rocky to determine that he's going to get rid of at least the e-mail regex, if not all of them.
HTH
- Scott
