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?
OK, so your request is to include the rule priority value in the
broken rule detail so you can do that sort?
I’ll add that to the wish list.
Rocky
From: pfQuinton
[mailto:cslanet@lhotka.net]
Sent: Tuesday, January 08, 2008 9:59 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Cross Property Priority
"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.
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?
The behavior you are observing is the way it is implemented.
> Would strict evaluation of all rules in priority
order be a bad thing to implement?
I don’t know. It would certainly be a fairly substantial
change in behavior, and would require rewriting a large chunk of the code that
checks rules (there’s all sorts of caching of rules, and the rules are
stored/cached per-property) – I think it would take major effort.
My biggest concern though, is the substantial change in behavior
– because this couldn’t be an option – the rewrite is too
substantial so it is one way or the other.
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
Copyright (c) Marimer LLC