Em Thu, 15 Oct 2009 16:06:05 -0300, Igor Drobiazko
<igor.drobia...@gmail.com> escreveu:
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.
Tapestry is aware of the property being validated too
(ValidationConstraintsGenerator). That's exactly how the @Validate
annotation works. So my suggestion is to add
ValidationConstraintsGenerators for each single-property annotation
(@NotNull, @Email, @Size, @Length, etc), something that can be done with
the existing Tapestry infrastructure. I have this already implemented for
Hibernate Validator 3 (for annotations that have some validation that
already exists in Tapestry) and I'll donate the code. Very little will
need to be changed (just package names, I guess). Then we'll need to add
support for object validation. We keep the value validation that we have
now and then add the object validation support. Better validate something
twice than never. :)
tapestry-crud-hibernate-validator can be found at
http://ars-machina.svn.sourceforge.net/viewvc/ars-machina/tapestry-crud-hibernate-validator/trunk/
(browse) and
https://ars-machina.svn.sourceforge.net/svnroot/ars-machina/tapestry-crud-hibernate-validator/trunk/
(checkout).
This fact makes the integration tricky if you care about the backward
compatibility of the Tapestry API.
Not that hard. :)
- I would like to add new maven module called 'tapestry-jsr303' or
'tapestry-bean-validation' (what is actually the better name?)
tapestry-bean-validation, so we shouldn't remember what each JSR number
means. :)
- 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.
I suggest it to be 'validate' (object is too generic in this case) and to
receive a List of objects, as a single form can edit more than one object
(specially when using Grid and AjaxFormLoop).
- the Form's 'object' parameter defaults to Form's container.
Ok!
- the Form component stores the value of the 'object' parameter in
environment service, let's say BeanVlidationContext, and pushes this
service into the environment.
Why?
- 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)?
I would propose an ObjectValidator interface added to Tapestry-IoC
(non-web applications would be able to use it too) as ordered pipelined
service.
I haven't seen the need for pushing the object being validated in the
environment. It is useful when one component needs to pass some value to
their inner components, and I don't see the need for this to do
validation. Why doesn't the form invoke the object validation pipeline
itself?
- BeanEditForm passes the value of its 'object' parameter into Form's
parameter 'object'.
Ok!
- the jsr 303 doesn't cover client validation, so this part can be done
by Tapestry.
This can be done by adding ValidationConstraintsGenerators for each
single-property annotation (@NotNull, @Email, @Size, @Length). Using my
tapestry-crud-hibernate-validator package, I hardly need to use t:validate
anymore, and I get all the client-side validation done. :)
--
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
