Validation Rules and Severity

bkirkman56 posted on Thursday, March 29, 2007

I have a situation where I need to validate that a qty is not over a certain max value. I originally used the common rules MaxValue rule to enforce this behavior. Normally, I would not save my data since IsValid would be false.

But I have a case where I want to increment the qty - save it even if it is invalid - then when I go to fetch my data validate the qty and display the brokenrule if it is invalid.

I tried using a custom rule and set the severity to warning which does allow me to save the data but on fetch the rule is not checked so I see no broken rule for my invalid qty.

Looking for ideas on how to fire the rule on a fetch operation.

ajj3085 replied on Thursday, March 29, 2007

You need to call ValidationRules.CheckRules after the fetch.

david.wendelken replied on Wednesday, April 04, 2007

The ability to save objects with broken rules (warning/fyi severity settings) has not been rippled throughout the framework.

The suggestion to use "ValidationRules.CheckRules();" after the data fetch will work for editable objects, but NOT for objects derived from ReadOnlyBase.

The concept "I may not be able to change this object, but I want to know what is wrong with it!" is a valid one that the framework does not yet support.

 

david.wendelken replied on Wednesday, April 04, 2007

david.wendelken:

The ability to save objects with broken rules (warning/fyi severity settings) has not been rippled throughout the framework.

The suggestion to use "ValidationRules.CheckRules();" after the data fetch will work for editable objects, but NOT for objects derived from ReadOnlyBase.

The concept "I may not be able to change this object, but I want to know what is wrong with it!" is a valid one that the framework does not yet support.

 

It looks like it might be really easy to modify ReadOnlyBase to handle rules to do this.

Think I'll create a ReadOnlyRuledBase and a ReadOnlyRuledListBase class.

bkirkman56 replied on Thursday, March 29, 2007

Found an answer with some help from a friend.

In my fetch I set the Property, not the internal variable, assigning it the value from the DB. This way the setter for the property gets called which would execute my ValidationRule.CheckRules(). The brokenrule then gets set. MarkOld() is called at the end of setting the values from the DB.

Next, I added a custom rule so that if the rule is broken it is only a warning using Severity.Warning. This made it so IsValid was not set to false when the rule is broken.

It now works as desired, allowing the invalid qty to be set (which is really more a "soft" error), saving the value and then whenever the item is retrieved it sets the brokenrule.

RRorije replied on Friday, March 30, 2007

I would not know whether there is a performance issue involved, but in the book the road is taken as described by ajj.

From the database the values are set to the private members and then when the fetch is completed ValidationRules.Checkrules is called.

I think there is a reason for that. It might that the rules are checked less often, but somebody else (for instance Rocky) knows the precise reason, maybe there is no difference whatsoever.

However, when it is working, why bother ;)

xal replied on Friday, March 30, 2007

There's a performance hit to setting the values through the properties.
Some of the reasons are:
-PropertyChanged events are "raised" (even though there's probably nobody is listening, at least there's a check).
-The object gets marked dirty during the process (even though root objects get marked clean by the dataportal after loading, you have to manually call MarkOld on children).
-Security checks have to be processed during the set of the properties (if you have CanWriteProperty coded).
-Rules may be processed more than once if you have dependant properties. This may even make the object invalid for a second because some validation may be using more than one prop to check it's state and since you're setting them all at the same time, the rule may run before all used props are set in the object, adding a broken rule and then removing it when all props are correctly set.

What's even worse, you may even get an exception on loading if the user performing the load has only read access to the object (or some of it's props), because even if it's only loading, you're still a user that's not allowed to set the prop.

I may have missed some reasons, but those are probably the most important ones.
Of course, if you can live with all of this, then that's ok... Some people do load the objects through the props (not me though).


Andrés