The rule of rules
Recently I’ve been doing some research about “rules” in the world of user interfaces (personal curiosity mostly). When you think about it many of the chores that UI developers have to do are simply “rules” on a particular piece of UI: validations, hide/show fields, change the value/data set of another field based on some condition(s). While many technologies and editors (e.g. ASP.net) have components that allow you to configure some of the above behaviors (e.g. Validators) the fact remains that you have to manually connect the dots and almost everybody ends up doing their own “rules/script” engine.
An interesting point that I keep coming back and forth is… what should the rule be attached to? An object (e.g. contact)? A particular field (e.g. name)? A particular form (e.g. a combination of fields and layout)? And there is really no good answer; there are pros and cons in all the alternatives. As usual, the lower you attach the rule the more reusable it becomes but also less flexible and useful; for example, you can attach a validation rule (e.g. isValidEmail) directly to a particular field but you require a form to apply a rule that involves the visual, not committed state of another field (ifAnotherFieldIsSelected then).
Anyhow, wouldn’t it be wonderful not to have to code chores like that ever?
