Announcement Announcement Module
Collapse
No announcement yet.
Rules Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Rules

    Hello,

    it seems that when creating a Rules object the caller has to specify a single implementation class the rules will be applied on.
    The method I am talking about is Rules.createRules(Class clazz).

    Wouldn't it be better if I could specify an interface, and the rules would be applied to all classes which implement that interface? That would be more consistent with Spring's overall interface-based approach.

    I think this could be fixed with changing method org.springframework.rules.Rules.supports(Class clazz). Currently it is:
    return clazz.equals(this.beanClass);
    I think it should be:
    return this.beanClass.isAssignableFrom(clazz);

  • #2
    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.

    Comment


    • #3
      Thanks, but something is still missing

      Thanks for the quick response.

      However, it still does not work. If I create a Rules object for
      an interface, the rules don't get applied if I have an object
      implementing that interface on a form. If I change the constructor
      parameter to Rules to the implementation class, it works.
      So something is still missing...

      I also noticed that you had removed the static method createRules(),
      so I assume that the constructors are meant to be invoked directly.
      Correct me if I'm wrong.

      This works:
      Code:
      Rules rules = new Rules(BusinessInterfaceImpl.class);
      This does not:
      Code:
      Rules rules = new Rules(BusinessInterface.class);

      Comment


      • #4
        Argh... thanks for the report... :-)

        Yes, they were removed as they were adding no value. Favor the constructor.

        Comment


        • #5
          Re: Thanks, but something is still missing

          Originally posted by vpeurala
          This works:
          Code:
          Rules rules = new Rules(BusinessInterfaceImpl.class);
          This does not:
          Code:
          Rules rules = new Rules(BusinessInterface.class);
          I've create a JIRA report for this.

          Comment

          Working...
          X