2

Given the following trait and domain class definitions:

@grails.validation.Validateable
trait SynchronizedData {
    String synchronizationId

    static constraints = {
        synchronizationId(blank: false, maxSize: 30, unique: true)
    }
}

class Carrier implements SynchronizedData {

    static constraints = {
        importFrom SynchronizedData
    }
}

the field "sychronizationId" in the domain class Carrier does not get the imported constraints from the SynchronizedData trait. Is this a limitation in the 2.5.x importFrom support that it doesn't import from traits? It does work when importing from a superclass.

Steve Hole
  • 348
  • 2
  • 12
  • Why would you make that a trait? – Jeff Scott Brown Jul 19 '16 at 21:23
  • Because I want a whole series of reusable domain patterns that I'd like to be able to apply to domain objects. SynchronizedData is just an example of one such pattern. I have about 20 others and by implementing multiple traits I can combine these patterns of use into business domains. Other examples include AccessControlledObject, GuidData, InternationalizedNameData etc. Up until traits we were forced to subclass which severely limited our ability to combine patterns. It all works, but it would be nice if importFrom worked for the constraints defined in the trait because many are complex. – Steve Hole Jul 19 '16 at 22:48
  • There are a number of reasons the is not likely to work. I don't think we have suggested anywhere in our docs that a trait could be made validateable but if we have, we probably should address that. – Jeff Scott Brown Jul 20 '16 at 13:40
  • 1
    OK, I understand that it isn't supported. I'm surprised that you think it strange to want to use traits to compose domain classes though. Why would a domain be any different than any other class where you want to combine common abstract characteristics? I want to provide reusable functionality include properties and associated methods that act on those properties within a number of domain classes. I didn't include any of the methods in the example because I didn't think they were pertinent. I'd like a larger discussion on the concept, but this probably isn't the place. Where can I do that? – Steve Hole Jul 20 '16 at 15:45
  • "I'm surprised that you think it strange to want to use traits to compose domain classes though." - I don't think that. In Grails 3 all domain classes do that. We add the corresponding traits at compile time. – Jeff Scott Brown Jul 20 '16 at 16:40
  • " I'd like a larger discussion on the concept, but this probably isn't the place. Where can I do that?" - If you wanted to do it locally you could seek out any JVM related user group. If you wanted to do it online you could do it in our Slack at grails.slack.com or on the mailing list at https://groups.google.com/forum/#!forum/grails-dev-discuss. – Jeff Scott Brown Jul 20 '16 at 16:42
  • The issue here isn't using traits to compose domain classes. The issue is there are several things in the validateable AST transformation that I expect will be problematic. – Jeff Scott Brown Jul 20 '16 at 16:43
  • Ah! So that means that support for features like importFrom that work with class definitions won't work and we may have problems with some of the validation features in 2.5.x if we use traits. Is that a fair summary? Are these features that are available in 3.x? – Steve Hole Jul 20 '16 at 19:05
  • The answer to the first questions is "yes" and the answer to the second is "no". – Jeff Scott Brown Jul 20 '16 at 19:15

0 Answers0