Changing Domain object's constraints on the fly.

[Mark Spritzler]

So, I have a basic constraints for my domain class, that will allow a few fields to be nullable. But later in my app, for another use case, I will need them to be not nullable. Now I can't just set it to be not nullable, because the domain object is also used as my UserDetails object in Spring Security, and those fields need allow nulls at the time of registration.

Anyway, I created two sets of constraints and made a "submitValidation" closure that gets called to swap the constraints, then do a validate() call, but that doesn't seem to do the magic trick.

class Band {

  static constraints = {
    username(blank: false, unique: true)
    passwd(blank: false)
    enabled()
    email(blank:false, email:true, unique:true)
    bandName(blank: false)
    mainImageURL(url:true, nullable:true)
    newsImageURL(url:true, nullable:true)
    tourImageURL(url:true, nullable:true)
    discographyImageURL(url:true, nullable:true)
    videoImageURL(url:true, nullable:true)
    bandAppName(nullable:true)
    description(widget:'textarea', nullable:true)
    paidFor()
  }

  static submitConstraints = {
      username(blank: false, unique: true)
      passwd(blank: false)
      enabled()
      email(blank:false, email:true, unique:true)
      bandName(blank: false)
      mainImageURL(url:true, nullable:false)
      newsImageURL(url:true, nullable:false)
      tourImageURL(url:true, nullable:false)
      discographyImageURL(url:true, nullable:false)
      videoImageURL(url:true, nullable:false)
      bandAppName(nullable:false)
      description(widget:'textarea', nullable:false)
      paidFor()
    }
  
  ....

  def submitValidate = {
    def currentConstraints = constraints
    constraints = submitConstraints
    this.validate()
    constraints = currentConstraints
  }

Does anyone have any other recommendations?

Thanks

Mark

[Gregg Bolinger]

I *think* that your scenario is the reason for Command Objects.

[Mark Spritzler]

Gregg Bolinger wrote:I *think* that your scenario is the reason for Command Objects.

Ouch, I like always using my domain objects as Form backing beans. With the Command object, that would mean i need to create an adapter class to get the values from one "domain" object to another. I'd actually rather do a whole validation method in my controller rather than another domain object like a command object.

Mark

[Mark Spritzler]

Actually it isn't what command objects are for. ;)

Grails Command Objects provide a simple mechanism to validate form fields that do not map directly to domain objects.

1) Actually there isn't any form fields on the page that will do the submit.
2) If there were fields, they all map directly to my Domain object.

Basically the Band object has its own form, which the original constraints are for.

There is a link on my left nav that is a "submit to app store" link (can be clicked at any time on any page), that will take the user to a purchase page.
when they click the submit to app store link, the method behind it will get the Band object from the Spring Security Context, since I am using the domain object as my User object for Spring Security, then it will call validate on the Band object, in which the new constraints need to be used to validate.

Does this make sense? There is no form with fields or a backing object needed.

Thanks

Mark

[Gregg Bolinger]

Yep, I get what you saying. What you really need is some sort of conditional validation. I've looked high and low for something like that, but haven't been able to track anything down. Let me know if you find something.

[Gregg Bolinger]

BTW, Rails has Conditional Validation. Maybe hit the grails mailing list?

[Mark Spritzler]

Gregg Bolinger wrote:BTW, Rails has Conditional Validation. Maybe hit the grails mailing list?

Thanks for looking. I was also trying to avoid the grails mailing list because then I get 100 emails from it just saying that it doesn't know if my post even got sent to the mailing list, that it was still "waiting" and this goes on for a good month.

Mark

[David Newton]

This is one reason I don't like model-based validation, which was one of my biggest beefs.

IMO it's solving a lower-level problem: in what states is this object completely invalid? But that stops working when the object is used in multiple contexts. Something like Costanza's Context-Oriented Programming makes sense--seems like a context could just throw something on top of an object that defines how it may be used depending on the current context.