Good point. I changed supports to isAssignable. You may associate rules for interfaces just as you can for classes.
Since we're on the subject of rules, here's an announcement of some recent work from our dev list:
I’ve added several new features to the declarative validation (rules) system this weekend, specifically:
Rules that depend on the value of more than one domain object properties are now evaluated when any of those dependent properties change—previously the rule was only evaluated when the “primary” property changed, which was obviously incorrect (as Ollie pointed out.)
You may now associate different sets of validation rules for different contexts (see the new methods in the RulesSource interface) – for example, a “create” use case context might apply a different set of rules than an “update” context for a given domain object.
In general, the Rules and RulesSource related classes have been refined, polished, and been made easier to extend.
Have fun with the new stuff—expect further improvements/refining here and keep the good feedback coming! Keith
P.S. I forgot to mention: you can see an illustration of a constraint whose outcome is determined by the value of more than one domain object property by running the latest PetClinic snapshot. Specifically, you can’t assign an Owner a first and last name that are equal (simple example, but it should get the point across.) Check out PetclinicValidationRulesSource for the new rule definition.
Keith Donald
Core Spring Development Team