I'd like to implement the capability to implement an BusinessBase object "repair" type method that knows how to fix a specific broken rule, with the most common case being that additional information is required before the object can be saved. (Yes, you could bind the data directly, but this might be a seldom used feature and you don't want to take up screen real-estate for it, or it might be scrolled off the screen in a grid).
The problem seems to be that the ValidationRules classes are so protected that it seems impractical, given a broken rule, to really know "which" rule it was programmatically.
The best I can come up with is to see what name CSLA generates for it, and possibly do a string comparison.
The idea I'm toying with is that the UI could inspect an object before saving it, and if it isn't valid, enumerate through the BrokenRulesCollection to see if there is anything that could be resolved by specifically prompting the user (versus just displaying an error provider or error message).
Has anyone ever tried anything like this?
I am not following you. You want to artificially remove the broken rule (even though it is still broken) so you can succesfully call Save()?
You can do that now, either by using the Warning severity instead of Error for the rule, or by overriding Save() and making it either not enforce the IsValid check, or having it ignore specific rules.
At least so I think?
No, I don't want to tinker with the rules, I really want to fix the object by eliminating the "cause" of the rule violation. I just wanted to reliably know "which" rule is broken, so the appropriate transformation can be attempted on the object (by setting properties) to cause the rule to be unbroken.
I just didn't see a way to reliably identify the original rule method from the BrokenRulesCollection -- maybe the rule name is good enough -- it seems to be something like rule://methodname/propertyname, but I didn't know how dependable this was.
After I originally posted this, I came up with another way to do what I wanted -- the rule methods can just set properties in the object that the consumer can use for interrogating why the object is broken. However, this requires that the object implementation itself be modified versus a completely external test.
The short and most general answer is that for any object, I would like to be able to determine programmatically "why" it is broken -- e.g. make logical decisions in the application itself based which broken rules are in the collection. The error message itself tells a user why it's broken, but certainly isn't much help to the application itself.
The only way I currently see to identify a specific rule is by the RuleName property, which seems tenuous at best (e.g. your code would break if you renamed the rule method or the name generation algorithm changed later), but if this is very unlikely to change in CSLA then I could make do with that.
If the consensus is that it's a bad idea to try to make logical decisions based on broken rules, then I can deal with that also and just go with a different approach.
The rule:// URI is reliable, at least during the time your app
is running. It is discussed in the two ebooks, and CSLA 3.0 includes the
RuleDescription class to help you easily parse the URI into its parts.
The whole point of the URI is to give the UI developer rich
information about the rules, so I do suggest using it.
Rocky
RockfordLhotka:
The rule:// URI is reliable, at least during the time your app is running.
OK, thanks -- this is helpful and I think answers my question. Is the only reason it might change between application invocations is that the rule arguments might be different (e.g. can I depend on everything else not changing?)
I recommend using the RuleDescription class to parse it. In 3.6 the format will change slightly compared to 3.5, because in 3.5 there's an edge case where a duplicate rule name could occur. In 3.6 I'm including the name of the type that contains the rule method in the URI to avoid that issue.
Anyone using RuleDescription won't notice a difference, but if you manually parse the URI you'll have to update your parse code.
But the only reason the methodName and propertyName parts of the URI would change is if you rename your rule method or rename your property.
Copyright (c) Marimer LLC