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.
Does anyone have any other recommendations?
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.
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.
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.
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.