(new to CSLA) - I am trying to do some collection validation, but it does not scale. I would like to write my own method that will loop through the collection without firing any additional events and if I find an object is invalid, I would like to manually set the property to be invalid, which would be reflected through the interface.
In short.
No - you cannot set a property to be invalid (have broken rule) directly by yourself.
IE: You are not allowed to manually alter the content of BrokenRulesCollection (whis is what makes an property/object Invalid)
Normally - this behavior is built-in to the CSLA Object structure.
When a child object gets Invalid it is reflected/available in all parents that the structure is Invalid.
And depending on the type of UI there are different ways of reflecting this in the Interface.
BUT, if you really need this and the standard built-in behavior doesn't fit you, you can
Thank you. The timely response is much appreciated.
The three steps you listed is basically what I did, but when the list has 100+ items, it takes quite some time for the validation to run.....more time than the users will find acceptable.
Basically, I have records with effective and expiration dates on them, and the records cannot over lap dates, e.g. the expiration date of one record cannot fall between the effective and expiration date of another.
I'll look into alternative methods to accomplish this check.
Hi,
I would put this as a single rule in the "parent" object of the list to check on ChildChanged event.
That rule should be responsible for checking that none of the child objects have overlapping date periods.
That's the path I decided to take, although I won't know which items in the collection are problematic, so I won't be able to highlight those in the list. Since the validation will be reflected as a user adds or edits a record, they will know what they are adding is the problem, just not which item it has a problem with.
What you might be running into is that if you use ChildChanged of the list to then tell the children which ones are valid and not valid (which makes sense) is that you might be getting a ton of noise in ChildChanged. ChildChanged fires a lot (used to or still does for meta-data), and you might be running your routine a great deal.
What I would suggest is to determine if this is what might be causing your problem by throwing some kind of static integer counter and see what happens when you make one change.
If this is the problem you might consider doing something like this in ChildChanged...
At the top, if _suppressChildChangedHandling is true, just return.
Around your routine which checks all children dates and validates which ones are a problem, just toggle the _suppressChildChangedHandling to true for the duration of your routine. It's possible you may need to do a couple OnPropertyChanged() calls after the routine to make sure certain bindings are refreshed, but this would cut down the unnecessary computations that may be happening.
Copyright (c) Marimer LLC