Allow reuse of a specified set of domain class constraints in command class constraints

It seems that this feature is desired for quite some time (long time for rapid Grails timeline ). I've found this thread on grails-dev mailing list: http://tinyurl.com/2b9xdy6

Permalinked post by Marc Palmer describes how it can look like. Additionally, it will be nice to have a possibility to filter imported constraints, for example, something like

class UserSignupCommand {
  ...
  static constraints = {
    ...
    importFrom UserProfile, [firstName:*, lastName:[size, validator]] 
  }
}

firstName:* or firstName[] will mean that all constraints should be imported, while non empty list will import only specified constrains.

This feature is really missing in Grails. Although above sample code works,
it would be great to have this explicitly supported in DSL.

This one seems pretty important. Is it possible to have it in next 1.3.5 release?

I'm seeing a lot of repetition and misconfiguration for not having a way to inherit constraints from domain to command classes it would be really nice to have this.

Not very DRY indeed, the importFrom-like method mentioned in the forum would be very helpfull

Here is a patch which proposes a solution for this issue (some tests are included). I've managed to implement reusage of domain class' constraints in commands. General syntax is

importFrom domainClass, include:["regExp1", "regExp2", ...], exclude:["regExp3", "regExp4", ...]

domainClass parameter is required, and it is of Class type. If only domain class is specified, constraints are imported from all domain property names which are also present in command class. This parameter must be specified first.

Lists include and exclude are both optional, and can be specified in any combination (none, one of them or both) and order. Their String entries are interpreted as regular expressions for matching property names against domain class.

Here is one example. Let say we have following Person and MySpecialCommand classes:

class Person {
    String firstName
    String middleName
    String lastName
    String telephone
    String email

    static constraints = {
        firstName(nullable:false, blank:false, maxSize:50)
        middleName(nullable:true, blank:false, maxSize:50)
        lastName(nullable:false, blank:false, maxSize:50)
        telephone(nullable:true, blank:false, maxSize:20, matches:'^[1-9][0-9]{4,19}$')
        email(nullable:true, blank:false, email:true)
    }
}

class MySpecialCommand {
    Long personId
    Long personVersion
    String firstName
    String middleName
    String lastName
    String telephone
    String email
    String emailConfirmation

    static constraints = {
        importFrom Person, include:[".*"], exclude:["m.*Name", "telephone"]

        email(nullable:false, blank:false, email:true)
        emailConfirmation(nullable:false, blank:false, email:true)
        emailConfirmation(validator: {emailConfirmationValue, personCommandInstance ->
            return emailConfirmationValue.equals(personCommandInstance.email)
        })
    }
}

In this example, MySpecialCommand imports all constraints from Person except middleName and telephone. After that it replaces constraint for email, and adds one of its own, emailConfirmation. If importFrom is specified last, imported constraints will replace already defined constraints in command class.

In attachment, I've also included demo app. It will work with patch applied. For convenience, in the archive is modifications folder which contains modified ConstrainedPropertyBuilder.java file. One can place it in src/java and run application with run-war command. I think run-app will not work.

It turns out that in the previous patch was a serious bug. I've removed these attachments.
Here is a fixed version with new sample app. Description from the previous comment is still relevant.

Hi Damir

This is a significant new feature and along with all the other patches you've submitted to accept these contributions I need you to sign an external committers agreement at: https://support.springsource.com/spring_committer_signup

Just login and select the project Grails. The reason for this to avoid a Linux/SCO-like legal situation for SpringSource.

Also since you've submitted so many patches have you considered forking the Github repo and submitting pull requests? It is much easier for us to accept contributions in that way.

Thanks again for your patches
Graeme

Pull request added: https://github.com/grails/grails-core/pull/22

Thanks for the contribution: https://github.com/grails/grails-core/commit/8313225b486b99ff64d919c7ee3d6fc4169962c1

This is great! I have been bitten by command objects that has different constraints than the domain class.

Awesome this is great.

The fix version is a bit misleading since this does not seem to be implemented on the 1.3.x branch.

Is there documentation for this feature anywhere now?

To clear some confusion this was not implemented in any 1.3.x branch (see discussion below). It would be helpful if someone could remove 1.3.6 from the fix version.

http://grails.1312388.n4.nabble.com/Some-fixes-are-missing-from-1-3-x-branch-td3035786.html

Add to doc

The commit (8313225b486b99ff64d919c7ee3d6fc4169962c1) is included in 2.0 Final, so this issue should be closed. Thanks, Bobby

Thanks Bobby

What happens with the nullable constraint, since that has a different default for domain classes and command objects? If it's not specified in a domain class and a command object imports the constraint, does the command object constraint have nullable: false or nullable: true?

It was long time ago , but as I can remember, mechanism is based on applied constraints, meaning, whichever constraint is applied on domain object, it will be applied on a command, including nullable: false as default for domain objects. I created simple app to test this, by using both DefaultConstraintEvaluator on command class and validate() method on command instance, and results confirm this.

If this is not desired, one can always modify specific constraint value in command class. For example, in domain class

  class Person {
    String firstName
    
    static constraints = {
      firstName(blank: false, maxSize: 50)
    }
  }

for firstName property, we have applied constraints of nullable: false, blank: false and maxSize: 50. If command class is specified as

  class PersonCommand {
    String firstName
    
    static constraints = {
      importFrom Person
      
      firstName(nullable: true)
    }
  }

this will result with constraints nullable: true, blank: false and maxSize: 50 for firstName property in command class, meaning only specified constraint will be modified, others, which are copied from domain object, are left untouched.

I think that nullable constraint behavior is same for domain and command classes, with difference how grails applies it to properties of each kind of class. I mean, if no constraints are specified at all for domain class property, nullable: false will be automatically added on that property. For command class property, if no constraints are specified, nullable will not be added, but if any other constraint is specified, nullable: false will be added to command class property. I might be mistaken with this, but I believe things works that way...