Braking rules that are not broken.

Braking rules that are not broken.

Old forum URL:

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

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:

or use 1 "generic rule2 for each property:

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

Starting from Csla 4.x

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


Copyright (c) Marimer LLC