2010/10/6 Emmanuel Bernard
>
> Too sad, that javax.validation.ValidatorContext is not defined as
>
> public interface ValidatorContext > {
>
> }
>
> If it were, we wouldn't need a dedicated method
> HibernateValidatorFactory#usingHibernateContext(), but
> HibernateValidatorFactory could be define
>
> Too sad, that javax.validation.ValidatorContext is not defined as
>
> public interface ValidatorContext > {
>
> }
>
> If it were, we wouldn't need a dedicated method
> HibernateValidatorFactory#usingHibernateContext(), but
> HibernateValidatorFactory could be defined as
>
> public interf
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
Hi,
answers inline.
Gunnar
2010/10/5 Emmanuel Bernard
> Not rebuild the factory, reusing it.
>
> regularValidator = factory.getValidator();
> failFastValidator = factory.unwrap(HibernateValidatorFactory.class)
>.usingHibernateContext()
>
Not rebuild the factory, reusing it.
regularValidator = factory.getValidator();
failFastValidator = factory.unwrap(HibernateValidatorFactory.class)
.usingHibernateContext()
.failFast(true)
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 :)
>>
>>
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
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:
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
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
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
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
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
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,
I like the idea. Emmanuel's performance test showed an execution time per
validation of 11 vs. 74 ms on my system, so there seems to be some
potential. Instead of having a "failFast" flag one could also introduce a
numeric parameter to control, when validation should stop. A value of "1"
would
That or slowish validations.
One typical use case is that:
if ( validator.validate(customer, StraightToValidationScreen.class).size() >0 )
{
//manual process
}
else {
//automatic process
}
BTW, I've committed a non scientific perf test that shows an average of 5x perf
improvement on an obj
What would be the usecase? Saving time in large object graphs where I am
only interested in whether there is a
failure at all? You really need LARGE object graphs to make this worth
while.
On Mon, 04 Oct 2010 15:45:34 +0200, Emmanuel Bernard
wrote:
> http://github.com/emmanuelbernard/hibe
17 matches
Mail list logo
