Ok, I thought about it a little bit. Would like to hear some objections before I start coding. The main challenge is the difference between validation mechanism in Tapestry and in jsr 303. In Tapestry a validator is only aware of the value being validated. The jsr 303 validators work with beans. You need to pass the entire bean even if you want to validate a single property.
http://anonsvn.jboss.org/repos/hibernate/beanvalidation/api/trunk/src/main/java/javax/validation/Validator.java This fact makes the integration tricky if you care about the backward compatibility of the Tapestry API. - I would like to add new maven module called 'tapestry-jsr303' or 'tapestry-bean-validation' (what is actually the better name?) - since tapestry validators are only aware of the value being validated, we need a new parameter for the Form component. Let's call it 'object' (or 'validate'). Once you want to use jsr303 validator you should pass the object to validate into this parameter. It can be a JavaBean or even a page/component. - the Form's 'object' parameter defaults to Form's container. - the Form component stores the value of the 'object' parameter in environment service, let's say BeanVlidationContext, and pushes this service into the environment. - the new module overrides the default implementation of the FieldValidatorDefaultSource by an implementation which uses jsr 303 validator. This implementation peeks the BeanVlidationContext from environment to obtain the bean to validate. Maybe a pipeline is a better alternative than overriding the service in order to mix both validator mechanism (tapestry and jsr303)? - BeanEditForm passes the value of its 'object' parameter into Form's parameter 'object'. - the jsr 303 doesn't cover client validation, so this part can be done by Tapestry. Does it make sense? Comments are welcome. On Wed, Oct 14, 2009 at 12:36 AM, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Em Tue, 13 Oct 2009 18:22:51 -0300, Igor Drobiazko < > igor.drobia...@gmail.com> escreveu: > > In this case the JSR 303 validation would take place inside the form >> component (not it is distributed across several fields). >> > > IMHO, it should be distributed across fields too, using > ValidationConstraintGenererator, so Tapestry can generate client-side code > to validate the fields. > > The mentioned >> parameter could default to the container of the form. >> > > Nice idea! > > > -- > Thiago H. de Paula Figueiredo > Independent Java consultant, developer, and instructor > http://www.arsmachina.com.br/thiago > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Best regards, Igor Drobiazko