CSLA .NET

Is there currently any means of ordering all broken rules (spanning different properities) by priority?  If there isn't, is it possible that BrokenRule could be given a the IRuleMethod's priority in later versions of CSLA so that the BrokenRuleCollection could be manually sorted afterwards?

So when ValidationRules.CheckRules() is called you want some properties to be checked before others?

Or when ValidationRules.CheckRules() is called you want all the rules for all properties to be assembled into a single list, sorted by priority and then checked?

---

Rocky

"Or when ValidationRules.CheckRules() is called you want all the rules for all properties to be assembled into a single list, sorted by priority and then checked?" -- Yes.

The order of their evaluation in my case is not important.  What is important is that the final BrokenRulesCollection be sorted by severity, then by priority.  We select the most "important" BrokenRule to display a message to user about what is wrong when all the rules are evaluated.

---

Rocky

Sorry to resurrect an old thread, but I ran into an issue related to this today.

I previously had the impression that when a set of rules would be evaluated as a result of calling CheckRules() or a property change, that *all* the potential rules to be evaluated would be executed in the order of priority, including dependent properties.

Evidently this isn't the case (at least not in the property changed case) -- the main property rules are checked first, then the dependencies, even if the dependent property rule has a higher priority.

Was this the intent? If so, it means you can't do cross-property short-circuiting, which I was trying to use to handle a complicated validation sequence that involved multiple properties.

Would strict evaluation of all rules in priority order be a bad thing to implement?

---

Rocky

Ok, thanks. When I first saw the rules being invoked in an unexpected order, I waded into the ValidationRules processing and it looked like it would just be a matter of collecting the rules for the various properties and sorting them before invoking them, but I can see how this would complex for cascading dependencies.

I've worked around it now that I understand it, but I did enjoy the temporary illusion that you could guarantee the processing order using the priorty (indpendent of property name)... :)

I think the behavior can not be changed now.

In regards to the complex property rule and multiple properties - I usually approach this from a different perspective.

1. I do not attach the rule to all the various properties - because then it gets run multiple times during unbinding. And it is only "real" once unbinding is complete so all the earlier runs of the rule were "a waste of time".

2. I attach the rule to a fake property name (one that is not in the class.) This means it is never run during unbinding. So when is it run?

3. I override IsValid and call ValidationRules.CheckRules("FakePropertyName") and then call MyBase.IsValid. So it is only run when you call IsValid from your UI or the Save command. You can determine where in your UI you want to call IsValid. Or you can add a new method to "check special rules" and have that method call this (and others like it.) Then you can call that in lots of places in your UI.

4. This complex rule has access to all the current values and can be properly evaluated once.

Joe

 

^^^^

That's an interesting idea, but I guess you're trading off the ability to use the error provider during the actual manipulation of the data by the user (although that may not be that big a limitation - certainly not my use case that prompted my entry into this thread as I'm considering not using an error provider at all for this case).

Question: Why do all the rules run during unbinding?

Question: Why do all the rules run during unbinding?

Answer: I have a large Web app. (I do not have an Winforms or WPF apps with UIs.)

Joe