Announcement Announcement Module
Collapse

Spring Modules forum decommissioned in favor of Spring Extensions

As the Spring Modules project has been replaced by the Spring Extensions (http://www.springsource.org/extensions) project, this forum has been decommissioned in favour of Spring Extensions one at:
http://forum.springsource.org/forumdisplay.php?f=44

Please see the Spring Extensions home page for a complete list of current projects in Java, .NET and ActionScript. You can also propose one if you want.

Cheers,
Costin Leau
SpringSource - http://www.SpringSource.com- Spring Training, Consulting, and Support - "From the Source"
http://twitter.com/costinl
See more
See less
Any advice on validation configuration with Groovy Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Any advice on validation configuration with Groovy

    Hi, I'm writing a library to support validation configuration definitions written in groovy. I'm using grails for some time and i think, the constraints are not adequate. So i'm working on this library. I think what annotations or xml does in "Bean Validation Framework" can be done with groovy. But i wonder what is the right approach?

    What i want is such a configuration for validation of a bean:
    public class CustomerRuleProvider {

    def rules = {

    global {
    gcode(value: {bean ->
    !{bean.loginName && bean.password }
    }, code: 'account.inconsistent')
    }

    property {
    loginName {
    notBlank(code: 'custom.not.blank.message', message: 'login name can not be blank', contexts:['update','safe'])
    minLength(value: 6, args: { [6] as Object[] })

    // we need to check nullability of x because notBlank and minLength will pass if loginName is null
    expr(code: 'invalidchar', value: "if (x != null ) {x.contains('-') == false} else true")
    }
    password {
    notNull()
    notBlank()
    length(min: 6, max: 10)

    // here i don't check nullability because there is notNull before this
    gcode(code: 'invalidchar', value: { it.contains('z') } )
    }
    email {
    notEmpty()
    email()
    }

    address {
    cascade()
    }
    }

    }

    def supports = [Customer.class]



    }

    I wrote a RuleBuilder in groovy to handle this closure to provide a BeanValidationConfiguration and also i wrote the individual PropertyValidationDefinitionHandler counterparts for all unique,notNull etc so that they handle groovy configurations. Also, the "gcode" definition is a groovy closure for those ( like me ) who wants to write a closure instead of a string expression. Anyway, I have a GroovyConditionExpressionParser and GroovyFunctionExpressionParser but i prefer the closure anyway. Each configuration item ( unique, notNull .. ) can have applyIf, message, code and other parameters which can be used in annotation configurations.

    For groovy expressions, I used Eval.x method where the object or an individual property can be referenced with "x" variable.

    This works fine but i'm not sure about the approach for loading these configurations.
    1. I can put some placeholder interface on all of these rule providers and with an initializing bean, i can find them with ctx.getBeansOfType method and load configurations from these files and put them in a hashmap cache with the supported classes as keys.
    2. I don't use an interface ( a more groovy approach i think ) and i can provide a naming convention such as "....ValidationRuleProvider" and with a context-component-scan definition parser, i can find these bean definitions and register them.
    3. sth that i don't have any idea

    But whatever is the way we load them, i think these should be reloadable so that groovy can shine so that in somewhere i should change the definition to register a GroovyScriptFactory for each of these classes to properly reload them when source file is changed. Do we need a new child context for this kind of logic, i don't know. Also i want this library to be used without grails, in any java-groovy application. In grails i think a kind of plugin can easily handle this, but i think that Bean Validation Framework's configurationByClass approach in both validating with BeanValidator and loading with a loader is very flexible. So I didn't try to invent sth other than this approach. I just wanted to do the same thing with a configuration language other than annotations or xml. And an expression language other than valang which is already good but not as familiar as groovy to me.

    I'm waiting for any idea or advice.
Working...
X