BrokenRule: Bug or intended behavior?

ajj3085 posted on Monday, February 02, 2009

I have a rule method which looks like this:
        private static bool RequireCategory(
            Document target,
            RuleArgs e
        ) {
            bool result;

            result = CommonRules.StringRequired( target, e );
            if ( !result ) {
                if ( target.isLocked || target.IsClosed ) {
                    e.Severity = RuleSeverity.Warning;
                }
            }

            return result;
        }

Now, the first time it's run on one of my objects, the state is such that e.Severity is set to Warning.

Later, isLocked is set to false and IsClosed is false as well, so the e.Severity line is never hit. The odd thing (at least, it was unexpected to me!) e.Severity is set to Warning by the caller of RequireCategory. In other words, it seems to remember that it was set to be a warning last time it ran, and continues to do so. I thought it was the rule method's sole responsiblity to properly set Severity to Warning or Info.. that it should always be Error by default.

So... bug, or by design?

rsbaker0 replied on Monday, February 02, 2009

Do you actually see e.Severity being changed back to warning before the rule is called, or is CSLA just holding onto the last RuleArgs reference that was passed in and reusing it over and over (and hence is just retaining any changes you made to it)?

ajj3085 replied on Monday, February 02, 2009

Hmm... I didn't actually look at the Csla code. But I inspected the RuleArgs object instance before ANY line in my rule handler executed, and it was already set to Warning.

It looks like RuleMethod keeps a reference to the same RuleArgs and passes it each time. So I guess this is by design.

RockfordLhotka replied on Monday, February 02, 2009

Yes this is by design. The RuleArgs object is created at the time AddRule() is called - in fact you can create your own RuleArgs object (and often do if you use anything beyond the simplest rules).