Braking rules that are not broken.

rxelizondo posted on Monday, July 25, 2011

 

I REALLY hate property rules that depend on other properties because I can never make up my mind on how to deal with these type of broken rules.

The canonical example is the Start and End time properties when both of these properties reside on the same object. For example, supposed that “Start Time” has a value of 1/1/2010 and “End Time” a value of 1/1/2009. What is broken here? Is it that “Start Time” should be lower than “End Time”?  -Or - is it that “End Time” should be higher than “Start Time”? You really can’t tell because is not possible for a developer to anticipate what date values (Start or End time) may be correct. So my guess is that what most people would do when presented with this predicament is to add a broken rule to both properties but that seems wrong to me because one of the properties could be correct so why mark that property as broken?

What works for me is to have an object level broken rule essentially detached from the Start and End times but I am wondering if I am the only one that is doing something like that.

How do you normally deal with situation like the one explained above?

Thank you. 

 

Marjon1 replied on Monday, July 25, 2011

Generally in a case like this I would determine one property only as the primary, in this case I would nominate end-date and build the rule and then also add a start-date as a dependent property (using 3.8 rules engine). So that when the start date value was changed it will fire the end-date business rules and only that property will be marked as broken. While this can cause some confusion, like you said it's better than showing both properties as invalid.

The other example of this is we have a payslip production method which when set to email, the email address must be entered and valid. So while the user may change one property, it actually fires rules of for another and thus invalidates that property.

We aren't using the latest 4.0 rules engine yet, so I'm unsure as to the best practices in that circumstances; but I imagine the principles wouldn't have changed. Also don't forget that CSLAContrib has a set of common rules, so you could see what they do for these sort of rules.

JonnyBee replied on Monday, July 25, 2011

I'd probably add a

• LessThan rule to StartDate and
• GreaterThan rule to EndDate
• Dependency rule from StartDate to EndDate
• Dependency rule from EndDate to StartDate

so that both fields would show an Error icon. If you don't want Error for both fields then StartDate would be set as Warning.

Starting from CSLA 4.2 you could solve this with just 1-one custom rule that would:

• Have StartDate and EndDate as InputProperties
• Set message and level on both EndDate and StartDate
• Will treat InputProperties as implicit Dependency (so rule will run when one of InputProperties is changed)

or use 1 "generic rule2 for each property:

• LessThan rule to StartDate and
• GreaterThan rule to EndDate

So from 4.2 one property rule can set message on other properties than just PrimaryProperty. And considering both AffectedProperties and InputProperties as dependencies should eliminate much of the need for declaring Dependencies between properties.

The EMail address problem I would have
Pre 4.x

• Override CanWriteProperty and add a test for EMail address is writable only when PayslipProductionMethod is EMail
• Add Dependency rule from PayslipProductionMethod to EMail
• Use Rule Priority to declare
  
  • StopIfNotCanWrite at Priority -1 (ie Shortcut rule for property if not Writable, even works with DataAnnotation)
  • Required rule at default priority (0) either as DataAnnotation rule or Required rule.

Starting from Csla 4.x

• Add an Authz rule for Write to EMail property that will check PayslipProductionMethod
• Add a Dependency rule from PayslipProductionMethod to EMail
• Use Rule Priority to declare
  
  • StopIfNotCanWrite at Priority -1 (ie Shortcut rule for property if not writable, even works with DataAnnotation)
  • Required rule at default priority (0) either as DataAnnotation rule or Required rule.

The LessThan, GreaterThan, StopIfNotCanWrite and more rules are available on CslaContrib.