You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Olle Hallin <ol...@hit.se> on 2009/10/13 21:38:05 UTC
Hibernate Validator 4 released, any plans for adding support in T5?
Hi,
Now when Hibernate Validator 4 and soon also the JSR-303 spec itself is
released, it wouldbe great to learn if someone is planning to add support
for it in Tapestry 5.
Are there any such plans?
Olle Hallin
Senior Java Developer and Architect
olle.hallin@crisp.se
www.crisp.se
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 13 Oct 2009 16:38:05 -0300, Olle Hallin <ol...@hit.se>
escreveu:
> Hi,
Hi!
> Now when Hibernate Validator 4 and soon also the JSR-303 spec itself is
> released, it wouldbe great to learn if someone is planning to add support
> for it in Tapestry 5.
I've written a Hibernate Validator 3 integration package, so I guess it
will be an easy transition. I'm not going to promise any dates, though.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 15 Oct 2009 19:48:22 -0300, Igor Drobiazko
<ig...@gmail.com> escreveu:
> Thiago, the jsr 303 is much more than annotations: there are validation
> groups, there is xml based validation definition. Why shall we cut all
> these features?
I never proposed to cut these features nor I would, as it wouldn't make
any sense. I'm just proposed to add ValidationConstraintGenerators
alongside the full JSR 303 features. I'm proposing to do all you want to
do (object-level validation using JSR 303) *plus* the property-level
annotation support.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 15 Oct 2009 20:42:52 -0300, Igor Drobiazko
<ig...@gmail.com> escreveu:
> Jsr 303 validator return a set of constraints violetions. All
> informations you have is the error message and property path. Now you
> have to find the field a property is mapped to. the method recorderror
> expects a field, not a property name. So some extra code is needed to
> find the field.
You're absolutely right. I stumbled at this while implementing my
Hibernate Validator package. My partial solution was to record errors
without specifying the component.
Somebody in the user list already proposed to add a recordError(String
componentId, String message) method to Form. It's a very good idea, as we
wouldn't need to inject the field component to record an error for it. ;)
> Let me start the work, so we can discuss code. The approach i suggest
> requires really few changes. We can still change the implementation and
> adjust to our needs..
That's a very good idea! :) Unfortunately, I can't code what I'm proposing
now (it shouldn't take of lot of code) because I'm in the last steps of
launching my current project, www.pronutricionista.com.br.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Hibernate Validator 4 released, any plans for adding support in T5?
Posted by Igor Drobiazko <ig...@gmail.com>.
Jsr 303 validator return a set of constraints violetions. All
informations you have is the error message and property path. Now you
have to find the field a property is mapped to. the method recorderror
expects a field, not a property name. So some extra code is needed to
find the field.
Let me start the work, so we can discuss code. The approach i suggest
requires really few changes. We can still change the implementation
and adjust to our needs..
16.10.2009, в 01:27, "Thiago H. de Paula Figueiredo"
<th...@gmail.com> написал(а):
> Em Thu, 15 Oct 2009 20:16:51 -0300, Igor Drobiazko <igor.drobiazko@gmail.com
> > escreveu:
>
>> A further argument not to do the validation inside the form component
>> is the decoration of fields. In case of errors more code is needed to
>> highlight the fields in error.
>
> I'm proposing that the Form component should invoke the object
> validation service after the property-level validation is done and
> then registering the erros using form.recordError();. This way,
> field decoration works as it works now,
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 15 Oct 2009 20:16:51 -0300, Igor Drobiazko
<ig...@gmail.com> escreveu:
> A further argument not to do the validation inside the form component
> is the decoration of fields. In case of errors more code is needed to
> highlight the fields in error.
I'm proposing that the Form component should invoke the object validation
service after the property-level validation is done and then registering
the erros using form.recordError();. This way, field decoration works as
it works now,
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Hibernate Validator 4 released, any plans for adding support in T5?
Posted by Igor Drobiazko <ig...@gmail.com>.
A further argument not to do the validation inside the form component
is the decoration of fields. In case of errors more code is needed to
highlight the fields in error.
I invite the others to participate in this discussion.
16.10.2009, в 00:48, Igor Drobiazko <ig...@gmail.com>
написал(а):
> Thiago, the jsr 303 is much more than annotations: there are
> validation groups, there is xml based validation definition. Why
> shall we cut all these features? How do you want to generate
> constraints which are provided inside xml? There is no way to get
> them from ValidationConstraintGenerator. I know there is no xml
> inside Tapestry but we should not limit the possibilities of the
> JSR. The jsr validation should work same, independent form the
> source the constraints are defined in (annotations or xml). That's
> why I would prefer the approach I suggested.
>
> IMO, the integration should be very simple. No extra code, no
> limitations of the jsr. It should just work.
>
> It looks like it is the matter of taste. What do the others think
> about it?
>
> On Thu, Oct 15, 2009 at 10:55 PM, Thiago H. de Paula Figueiredo <thiagohp@gmail.com
> > wrote:
> Em Thu, 15 Oct 2009 17:18:38 -0300, Igor Drobiazko <igor.drobiazko@gmail.com
> > escreveu:
>
>
> Well, I don't think it is a good idea to create adapters for every
> single
> annotation from jsr 303. Every time they add a new annotation, we
> have to
> adjust our code.
>
> I guess you didn't get my suggestion yet. My idea is to add both
> ValidationConstraintGenerator validation (so client-side validation
> is added automatically) and object-wide validation. Both together.
> This way, validation using Tapestry or not using Tapestry will yield
> the exact same result.
>
> Just emphisizing a little more: we need
> ValidationConstraintGenerator for client-side validation to be added
> automatically.
>
>
> One of the key feature of the jsr 303 is the easy to add
> new validators. You create a new annotation which is validated by a
> ConstraintValidator.
>
> IMHO, this is not a problem at all. *We don't need to add a
> ValidationConstraintGenerator for each possible validation
> annotation*. All I'm suggesting to add
> ValidationConstraintGenerators for every matching Tapestry
> validator. We'll validate objects themselves, so every annotation is
> validated, having a ValidationConstraintGenerator for it or not. And
> we'll also need to validate the object itself using JSR 303, so
> we're not losing any validation by not having a
> ValidationConstraintGenerator for each annotation.
>
>
> The reason is that the jsr 303 code should work without to write
> Tapestry
> code. How should FieldValidatorDefaultSource or
> ValidationConstraintGenerator know the bean being validated? You
> need to
> pass the bean from Form component to the place where jsr 303
> validation
> takes place.
>
> Same reasoning as above: ValidationConstraintGenerators in addition
> to object-level validation, not replacing them.
>
>
> Because now validation takes place inside the fields. The method
> 'processSubmission' does the job.
>
> We want to add validation that can't be done field-by-field, so,
> IMHO, propagating object validation to field components will not help.
>
> Summary: I want to have what Tapestry does now (field-based
> validation) used *together* with the new object-based validation
> we'll add.
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
>
>
> --
> Best regards,
>
> Igor Drobiazko
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by Igor Drobiazko <ig...@gmail.com>.
Thiago, the jsr 303 is much more than annotations: there are validation
groups, there is xml based validation definition. Why shall we cut all these
features? How do you want to generate constraints which are provided inside
xml? There is no way to get them from ValidationConstraintGenerator. I know
there is no xml inside Tapestry but we should not limit the possibilities of
the JSR. The jsr validation should work same, independent form the source
the constraints are defined in (annotations or xml). That's why I would
prefer the approach I suggested.
IMO, the integration should be very simple. No extra code, no limitations of
the jsr. It should just work.
It looks like it is the matter of taste. What do the others think about it?
On Thu, Oct 15, 2009 at 10:55 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Em Thu, 15 Oct 2009 17:18:38 -0300, Igor Drobiazko <
> igor.drobiazko@gmail.com> escreveu:
>
> Well, I don't think it is a good idea to create adapters for every single
>> annotation from jsr 303. Every time they add a new annotation, we have to
>> adjust our code.
>>
>
> I guess you didn't get my suggestion yet. My idea is to add both
> ValidationConstraintGenerator validation (so client-side validation is added
> automatically) and object-wide validation. Both together. This way,
> validation using Tapestry or not using Tapestry will yield the exact same
> result.
>
> Just emphisizing a little more: we need ValidationConstraintGenerator for
> client-side validation to be added automatically.
>
> One of the key feature of the jsr 303 is the easy to add
>> new validators. You create a new annotation which is validated by a
>> ConstraintValidator.
>>
>
> IMHO, this is not a problem at all. *We don't need to add a
> ValidationConstraintGenerator for each possible validation annotation*. All
> I'm suggesting to add ValidationConstraintGenerators for every matching
> Tapestry validator. We'll validate objects themselves, so every annotation
> is validated, having a ValidationConstraintGenerator for it or not. And
> we'll also need to validate the object itself using JSR 303, so we're not
> losing any validation by not having a ValidationConstraintGenerator for each
> annotation.
>
> The reason is that the jsr 303 code should work without to write Tapestry
>> code. How should FieldValidatorDefaultSource or
>> ValidationConstraintGenerator know the bean being validated? You need to
>> pass the bean from Form component to the place where jsr 303 validation
>> takes place.
>>
>
> Same reasoning as above: ValidationConstraintGenerators in addition to
> object-level validation, not replacing them.
>
> Because now validation takes place inside the fields. The method
>> 'processSubmission' does the job.
>>
>
> We want to add validation that can't be done field-by-field, so, IMHO,
> propagating object validation to field components will not help.
>
> Summary: I want to have what Tapestry does now (field-based validation)
> used *together* with the new object-based validation we'll add.
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 15 Oct 2009 17:18:38 -0300, Igor Drobiazko
<ig...@gmail.com> escreveu:
> Well, I don't think it is a good idea to create adapters for every single
> annotation from jsr 303. Every time they add a new annotation, we have to
> adjust our code.
I guess you didn't get my suggestion yet. My idea is to add both
ValidationConstraintGenerator validation (so client-side validation is
added automatically) and object-wide validation. Both together. This way,
validation using Tapestry or not using Tapestry will yield the exact same
result.
Just emphisizing a little more: we need ValidationConstraintGenerator for
client-side validation to be added automatically.
> One of the key feature of the jsr 303 is the easy to add
> new validators. You create a new annotation which is validated by a
> ConstraintValidator.
IMHO, this is not a problem at all. *We don't need to add a
ValidationConstraintGenerator for each possible validation annotation*.
All I'm suggesting to add ValidationConstraintGenerators for every
matching Tapestry validator. We'll validate objects themselves, so every
annotation is validated, having a ValidationConstraintGenerator for it or
not. And we'll also need to validate the object itself using JSR 303, so
we're not losing any validation by not having a
ValidationConstraintGenerator for each annotation.
> The reason is that the jsr 303 code should work without to write Tapestry
> code. How should FieldValidatorDefaultSource or
> ValidationConstraintGenerator know the bean being validated? You need to
> pass the bean from Form component to the place where jsr 303 validation
> takes place.
Same reasoning as above: ValidationConstraintGenerators in addition to
object-level validation, not replacing them.
> Because now validation takes place inside the fields. The method
> 'processSubmission' does the job.
We want to add validation that can't be done field-by-field, so, IMHO,
propagating object validation to field components will not help.
Summary: I want to have what Tapestry does now (field-based validation)
used *together* with the new object-based validation we'll add.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by Igor Drobiazko <ig...@gmail.com>.
On Thu, Oct 15, 2009 at 9:43 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Em Thu, 15 Oct 2009 16:06:05 -0300, Igor Drobiazko <
> igor.drobiazko@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. :)
>
Well, I don't think it is a good idea to create adapters for every single
annotation from jsr 303. Every time they add a new annotation, we have to
adjust our code. One of the key feature of the jsr 303 is the easy to add
new validators. You create a new annotation which is validated by a
ConstraintValidator.
http://anonsvn.jboss.org/repos/hibernate/beanvalidation/api/trunk/src/main/java/javax/validation/ConstraintValidator.java
Why shall we bloat Tapestry code unnecessary? Just image you want to add
your own annotation @MyFavoriteAnnotation. Why should you ever write
Tapestry code for it? You add the annotation, annotate your classes and
that's it. No more work should be necessary. The new should not be upgraded
every time jsr 303 guys add a new annotation. The same is when you add your
own annotations.
>
> 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. :)
This is fine.
>
>
> - 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 reason is that the jsr 303 code should work without to write Tapestry
code. How should FieldValidatorDefaultSource or
ValidationConstraintGenerator know the bean being validated? You need to
pass the bean from Form component to the place where jsr 303 validation
takes place.
>
>
> - 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?
Because now validation takes place inside the fields. The method
'processSubmission' does the job.
>
>
> - 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. :)
Again, why shall we add some much classes?
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 15 Oct 2009 16:06:05 -0300, Igor Drobiazko
<ig...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by Igor Drobiazko <ig...@gmail.com>.
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 <
thiagohp@gmail.com> wrote:
> Em Tue, 13 Oct 2009 18:22:51 -0300, Igor Drobiazko <
> igor.drobiazko@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 13 Oct 2009 18:22:51 -0300, Igor Drobiazko
<ig...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by Igor Drobiazko <ig...@gmail.com>.
On Tue, Oct 13, 2009 at 11:03 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Em Tue, 13 Oct 2009 17:53:58 -0300, Igor Drobiazko <
> igor.drobiazko@gmail.com> escreveu:
>
> The integration of the JSR 303 should not only allow you to use the JSR
>> annotations like @NotNull but also allow you to use the validation
>> mechanism provided by the implementation of the JSR like hibernate validator
>> 4.
>>
>
> I agree 100%.
>
> The integration should not force you to write any tapestry specific code
>> to use JSR 303, IMO. It should just work.
>>
>
> I agree 100% too.
>
> Furthermore the suggested approach
>> doesn't work for all annotations provided by JSR 303 because there are
>> less validators in Tapestry than in the JSR.
>>
>
> That's why I said that approach is a partial solution and some object
> validation interface needs to be defined, plus some way to tell Tapestry
> what object should be validated. Maybe some Form parameter to tell which
> objects should be validated. BeanEditForm already has an object parameter,
> so almost no additional code needs to be added.
In this case the JSR 303 validation would take place inside the form
component (not it is distributed across several fields). The mentioned
parameter could default to the container of the form.
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 13 Oct 2009 17:53:58 -0300, Igor Drobiazko
<ig...@gmail.com> escreveu:
> The integration of the JSR 303 should not only allow you to use the JSR
> annotations like @NotNull but also allow you to use the validation
> mechanism provided by the implementation of the JSR like hibernate
> validator 4.
I agree 100%.
> The integration should not force you to write any tapestry specific code
> to use JSR 303, IMO. It should just work.
I agree 100% too.
> Furthermore the suggested approach
> doesn't work for all annotations provided by JSR 303 because there are
> less validators in Tapestry than in the JSR.
That's why I said that approach is a partial solution and some object
validation interface needs to be defined, plus some way to tell Tapestry
what object should be validated. Maybe some Form parameter to tell which
objects should be validated. BeanEditForm already has an object parameter,
so almost no additional code needs to be added.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by Igor Drobiazko <ig...@gmail.com>.
The integration of the JSR 303 should not only allow you to use the JSR
annotations like @NotNull but also allow you to use the validation mechanism
provided by the implementation of the JSR like hibernate validator 4. The
integration should not force you to write any tapestry specific code to use
JSR 303, IMO. It should just work. Furthermore the suggested approach
doesn't work for all annotations provided by JSR 303 because there are less
validators in Tapestry than in the JSR.
On Tue, Oct 13, 2009 at 10:42 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Em Tue, 13 Oct 2009 17:31:14 -0300, Igor Drobiazko <
> igor.drobiazko@gmail.com> escreveu:
>
> If I understood you correctly you suggest the approach of the annotation
>> based ValidationConstraintGenerator. Right?
>>
>
> Right. It does not solve the whole problem, but solve it partially and
> elegantly. It just reuses the annotations to add the validation constraints
> you'd need to add manually.
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 13 Oct 2009 17:31:14 -0300, Igor Drobiazko
<ig...@gmail.com> escreveu:
> If I understood you correctly you suggest the approach of the annotation
> based ValidationConstraintGenerator. Right?
Right. It does not solve the whole problem, but solve it partially and
elegantly. It just reuses the annotations to add the validation
constraints you'd need to add manually.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by Igor Drobiazko <ig...@gmail.com>.
If I understood you correctly you suggest the approach of the annotation
based ValidationConstraintGenerator. Right?
On Tue, Oct 13, 2009 at 10:14 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Em Tue, 13 Oct 2009 16:59:35 -0300, Igor Drobiazko <
> igor.drobiazko@gmail.com> escreveu:
>
> One thing that is easy to do is to provide Validator implementations based
>>> on annotations (@NotNull -> required, @Min(n) -> min=n), etc.
>>>
>>
> I would not do it this way. Just image a bean which is used in several
>> projects (rich clients and tapestry apps). You want your validation work
>> same in all your apps.
>>
>
> I'm not following you: why it would work differently in different apps, as
> long as they're using the same validation annotation API? I'm already using
> that approach and it works very well.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 13 Oct 2009 16:59:35 -0300, Igor Drobiazko
<ig...@gmail.com> escreveu:
>> One thing that is easy to do is to provide Validator implementations
>> based on annotations (@NotNull -> required, @Min(n) -> min=n), etc.
> I would not do it this way. Just image a bean which is used in several
> projects (rich clients and tapestry apps). You want your validation work
> same in all your apps.
I'm not following you: why it would work differently in different apps, as
long as they're using the same validation annotation API? I'm already
using that approach and it works very well.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by Igor Drobiazko <ig...@gmail.com>.
On Tue, Oct 13, 2009 at 9:50 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Em Tue, 13 Oct 2009 16:46:56 -0300, Igor Drobiazko <
> igor.drobiazko@gmail.com> escreveu:
>
> The integration of the JSR 303 is difficult without to break the
>> compatibility of the API beacuse the Tapestry validation mechanism is only
>> aware of a
>> value being validated.
>>
>
> One thing that is easy to do is to provide Validator implementations based
> on annotations (@NotNull -> required, @Min(n) -> min=n), etc.
>
I would not do it this way. Just image a bean which is used in several
projects (rich clients and tapestry apps). You want your validation work
same in all your apps.
> We'll probably need to define something like an ObjectValidator<T>
> interface to provide validation of whole objects, not only invividual
> properties.
I'll start the discussion in the dev list.
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 13 Oct 2009 16:46:56 -0300, Igor Drobiazko
<ig...@gmail.com> escreveu:
> The integration of the JSR 303 is difficult without to break the
> compatibility of the API beacuse the Tapestry validation mechanism is
> only aware of a
> value being validated.
One thing that is easy to do is to provide Validator implementations based
on annotations (@NotNull -> required, @Min(n) -> min=n), etc.
We'll probably need to define something like an ObjectValidator<T>
interface to provide validation of whole objects, not only invividual
properties.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Hibernate Validator 4 released, any plans for adding support in
T5?
Posted by Igor Drobiazko <ig...@gmail.com>.
The integration of the JSR 303 is one of the things on my roadmap for 5.2
release (as well as integration of JPA).
I had already a look into this but had no time to finalize the work. The
integration of the JSR 303 is difficult without to break the compatibility
of the API beacuse the Tapestry validation mechanism is only aware of a
value being validated.
On Tue, Oct 13, 2009 at 9:38 PM, Olle Hallin <ol...@hit.se> wrote:
> Hi,
> Now when Hibernate Validator 4 and soon also the JSR-303 spec itself is
> released, it wouldbe great to learn if someone is planning to add support
> for it in Tapestry 5.
>
> Are there any such plans?
>
> Olle Hallin
> Senior Java Developer and Architect
> olle.hallin@crisp.se
> www.crisp.se
>
--
Best regards,
Igor Drobiazko