If you have displayed an informational or warning regarding a property change, and then Save() the object, the messages survive the object being saved and persist afterwards.
In my case, the warning or information is no longer applicable after the save and I need to remove it.
For example, consider a warning like "Changing the item associated with this location will remove all purchasing history for the location". After you have saved the object, the warning no longer applies -- it's a done deal.
What is the right way to handle this?
After the object is saved it is not dirty, so perhaps your rule method can factor in the IsDirty value - never considering itself broken if the object isn't dirty.
Or do you have some other property that would indicate a state change after the object is saved? You could use that property in a similar manner.
Or if you don't have such a status property, you might want to add one. Basically what you are saying is that you have a set of rules that only apply when the object is in an unsaved state. And that's cool - you can easily add that extra conditional to your rules - but it does require that the object be able to know whether it is in that saved state or not.
OK. My rules do indeed factor in whether the object is dirty and calling CheckRules() again does clear them, but it just seemed a comparatively expensive way to clear the rules from the collection. I just wanted to be sure I was on the right track.
You sure did a "good" job of preventing direct modifications to the BrokenRulesCollection itself... :)
rsbaker0:
You sure did a "good" job of preventing direct modifications to the BrokenRulesCollection itself... :)
I desperately needed the ability to remove a broken rule from the collection and there was no way to do it within the framework. So I added it directly. I would have preferreed to override something in my intermeidate Base class, but I could not figure out a way to do it. So I suggest you just add the method, make note of it and when you upgrade, add it back. Actually, I think someone recently recommended using Partial Classes for these types of modifications so that you simply have to copy over your 1 file of "changes to the framework" and it should re-compile. Hmm - I may have to re-visit what I did and see if that will work.
Joe
^^^^^
Incidentally, something that has worked for me -- not for CSLA specifically but the idea is the same -- is to put the framework into SourceSafe (VSS) and label each "official" release.
If you want to make changes, just check out the files, edit the code and check it into VSS. When a new CSLA comes out, you check out the official CSLA files from the previous label (e.g. check out older revisions of the files where you have made changes), just overwrite them with the new ones and check them back in.
VSS will do a very good job of merging and you will let you use it's conflict resolver where there have been conflicting changes.
I desperately needed the ability to remove a broken rule from the collection and there was no way to do it within the framework. So I added it directly.
The problem is that if your rules run again, the warning will come back. The correct way is to have your rule setup up that it takes into account that you've saved it. Is CheckRules() really that expesive?
Maybe it's not too bad. My rules do exactly this, but what I'd really like do is just have a way to rerun only the "broken" rules.
One thing that makes the rule implementation efficient (seemingly) is that normally the rules are run only once when the object is created, and then only if a property changes. Having to call CheckRules() again arbitrarily to check all the rules after a valid object is saved seems wasteful, and doing specific checks seems like a maintenance issue.
Copyright (c) Marimer LLC