Hi again,
I was just wondering whether I should interpret the lack of answers as
"no, this is not interesting at all", or as "we have a lot of other
things to do and do not have time for this right now"?
Federico
Den 22.09.2010 09:08, skrev Federico Mancini:
>Hi all,
> I am new to the lis
Hi Frederico,
sorry for the late reply. I finally had some time to read through your
paper.
I think there are strong similarities between you work and Hibernate
Validator or
more specific the Bean Validation specification (JSR 303).
Property validation in the SHIP Validator is basically the s
Hi and thank you for your answer.
I am aware that our work is extremely similar to the jsr 303,
and that is exactly why I wanted to show it to you.
It just happened that we independently developed similar solutions for
the same problem, but
when we saw the specs for the jsr 303, we realized tha
Hi,
a use case might be a data-centric application, where you for performance
reasons don't want to validate graphs completely once a failure occured, but
don't want to face the user with single validation errors one after the
other either.
Specifying the validation order would surely be useful.
Hi,
Help and contributions are always welcome :)
I recommend you start with this page
http://community.jboss.org/wiki/ContributingtoHibernateValidator
It contains information on where and how to check out the source and how
to built the project.
Once you have a local checkout and made yourse
Where exactly do you want to add the parameter? To the
Validator.validateXYZ() methods?
On Tue, 05 Oct 2010 15:54:10 +0200, Gunnar Morling
wrote:
> Hi,
>
> a use case might be a data-centric application, where you for performance
> reasons don't want to validate graphs completely once a fai
public doStuff(@Param("name") String name, @Param("command") Object command) {
...
}
On 5 oct. 2010, at 16:07, Hardy Ferentschik wrote:
> Where exactly do you want to add the parameter? To the
> Validator.validateXYZ() methods?
>
>
> On Tue, 05 Oct 2010 15:54:10 +0200, Gunnar Morling
> w
I'd put it at the same place as the boolean parameter in Emmanuel's
prototype: when creating the ValidatorFactor/Validator (e.g.
inHibernateValidatorConfiguration).
So "parameter" was not meant as in "method parameter" but more as in
"configuration attribute" :-)
2010/10/5 Hardy Ferentschik
> Wh
If we /really/ want stopAfterNFailures, I'd go straight to it. It's easy to
implement and will confuse people less. But the number of failures will be a
guaranteed to be above int (if there are enough ;) ) and the order will be
unspecified though today we do breadth-first I believe which is what
oops reading Gunnar's answer, I'm probably answer the wrong question :)
On 5 oct. 2010, at 17:23, Emmanuel Bernard wrote:
> public doStuff(@Param("name") String name, @Param("command") Object command) {
>...
> }
>
> On 5 oct. 2010, at 16:07, Hardy Ferentschik wrote:
>
>> Where exactly do yo
Ok. Makes sense.
But why not overloading the validate methods? This way you can with the
same Validator dynamically change the
maximum number of failing constraints. In Emmanuel's case you would have
to rebuilt the factory.
--Hardy
On Tue, 05 Oct 2010 17:42:41 +0200, Gunnar Morling
wrote:
I was about to ask what you've been smoking ;-)
On Tue, 05 Oct 2010 17:45:23 +0200, Emmanuel Bernard
wrote:
> oops reading Gunnar's answer, I'm probably answer the wrong question :)
>
> On 5 oct. 2010, at 17:23, Emmanuel Bernard wrote:
>
>> public doStuff(@Param("name") String name, @Param("co
2010/10/5 Hardy Ferentschik :
> I was about to ask what you've been smoking ;-)
ROFL, It's always a lot of fun to follow this list :)
Cheers,
Sanne
>
> On Tue, 05 Oct 2010 17:45:23 +0200, Emmanuel Bernard
> wrote:
>
>> oops reading Gunnar's answer, I'm probably answer the wrong question :)
>>
>>
Not rebuild the factory, reusing it.
regularValidator = factory.getValidator();
failFastValidator = factory.unwrap(HibernateValidatorFactory.class)
.usingHibernateContext()
.failFast(true)
Hi,
answers inline.
Gunnar
2010/10/5 Emmanuel Bernard
> Not rebuild the factory, reusing it.
>
> regularValidator = factory.getValidator();
> failFastValidator = factory.unwrap(HibernateValidatorFactory.class)
>.usingHibernateContext()
>
On Oct 5, 2010, at 17:43, Emmanuel Bernard wrote:
> If we /really/ want stopAfterNFailures, I'd go straight to it. It's easy to
> implement and will confuse people less. But the number of failures will be a
> guaranteed to be above int (if there are enough ;) ) and the order will be
> unspecif
16 matches
Mail list logo
