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

Reply via email to