-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 
Author Message
 Post subject: Designproblem with JSR303 - prevent own reimplementation?
PostPosted: Sun Jul 21, 2013 5:55 pm 
Newbie

Joined: Thu Jul 05, 2007 5:30 pm
Posts: 8
Hi everybody,

I am on my way to re-implement what is provided by javax.validation to allow deep integration with my open source UI framework:
http://m-m-m.sourceforge.net/mmm-client/mmm-client-ui/index.html

To prevent reinventing the wheel I always wanted to use javax.validation as it is but the design of the API prevents to do so for what I have tried so far. What I want is that if I bind a UI widget to a bean property then the according validators shall be added automatically by the framework. With javax.validation I can not find a way to validate just a bean property without having it set in the parent bean instance.
What I would like to have is a way to get some validator for a given class and property that can just validate the property value (e.g. String, Date, custom Datatype, etc.). Is there a way to do this with JSR 303? I can not find any.
Otherwise I am forced to follow the entire design of JSR 303 and first create and populate the beans, then validate them and afterwards go through the constraint violations and try to fiddle some sort of matching these back to widgets. I personally think this is just wrong design.
I want to have a widget that accepts the raw datatype and is coulpled with the according validator without itself knowing the parent bean (that was only known by the databinding that created the validators). I have all this running with my own implementation and it is accepting most of the standard JSR 303 constraint annotations but reimplementing custom constraints and logic for groups, etc. would be a lot of wasted effort if I could go with the standard...
I can give you deep links into my code at githup if you are interested. Eveything is working in plain java (for JavaFX) as well as with GWT. The GWT port of JSR 303 is also kind of awkward as you have to annotate a list with ALL beans supported by the validator. For such case my own implementation for GWT is a lot more flexibile and easy to use. I already reimplemented many other features of the java world that were simply "not good enough" but as I am doing this all in my spare time I would love to focus on creating new features and added value with my open-source-project (e.g. I spend more than half a year of coding after java5 came out to support reflective property introspection that really supports generics - even today spring and other frameworks fail to do this correct).

BTW: Where can I provide a locale for the validation if I want to do validation on the server-side for a webapp with multi-language support?

Thanks for your feedback
Jörg


Top
 Profile  
 
 Post subject: Re: Designproblem with JSR303 - prevent own reimplementation?
PostPosted: Thu Jul 25, 2013 3:46 pm 
Newbie

Joined: Thu Jul 05, 2007 5:30 pm
Posts: 8
Maybe the topic is misleading. IMHO everything is already there in the implementation. Is it possible to extend the API of javax.validation in the future? We would need Validator.validateProperty(Class<T> beanClass, String propertyName, Object propertyValue, Class<?>... groups)
so the existing method Validator.validateProperty(T object, String propertyName, Class<?>... groups) would only need to get the property from "object" and delegate to the new method where the rest of the implementation would remain.
This would be extremely helpful for client validation flexibility.


Top
 Profile  
 
 Post subject: Re: Designproblem with JSR303 - prevent own reimplementation?
PostPosted: Wed Aug 07, 2013 3:15 am 
Hibernate Team
Hibernate Team

Joined: Sat Jan 24, 2009 12:46 pm
Posts: 388
Have you had a look at Validator#validateValue()? This does exactly what you describe, validate the value of a property of a given type without the need to put into the model hosting the property.

Hth,

--Gunnar

_________________
Visit my blog at http://musingsofaprogrammingaddict.blogspot.com/


Top
 Profile  
 
 Post subject: Re: Designproblem with JSR303 - prevent own reimplementation?
PostPosted: Fri Aug 09, 2013 4:20 pm 
Newbie

Joined: Thu Jul 05, 2007 5:30 pm
Posts: 8
Hi Gunnar,

thanks for your response. Shame one me - it seems so obvious now... No idea why I missed it.
However, great that your API already supports my use-case.

Now I only need to find a way to check if a field is mandatory so I can mark their labels automatically in the UI.
I started with getConstraintsForClass(beanClass).getConstraintsForProperty(propertyName).getConstraintDescriptors() and loop over these. But then comes the tricky part. If I use getAnnotation() I will not hit the constraint annotations that are themselves annotated with @NotNull or the like. On the other hand getConstraintValidatorClasses() is also tricky as e.g. @NotNull has no (standardized) validator class.
So for the moment I ensure that empty values are provided as null by my widgets and on setup I just call validateValue for each property with a value of null and see if the resulting set is empty or not. Not elegant but should do it...

Thanks a lot
Jörg


Top
 Profile  
 
 Post subject: Re: Designproblem with JSR303 - prevent own reimplementation?
PostPosted: Thu Aug 15, 2013 3:59 am 
Hibernate Team
Hibernate Team

Joined: Sat Jan 24, 2009 12:46 pm
Posts: 388
You also can (recursively) retrieve metadata about composing constraints via ConstraintDescriptor#getComposingConstraints(). That way you can find out whether a given constraint type is meta-annotated with @NotNull.

--Gunnar

_________________
Visit my blog at http://musingsofaprogrammingaddict.blogspot.com/


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.