-->
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: Defining a new constraint without a new annotation
PostPosted: Fri Apr 11, 2008 1:15 pm 
Beginner
Beginner

Joined: Fri Jan 14, 2005 7:47 am
Posts: 37
Location: Spain
It's very frecuent in business application to write not reusable validations. In this case, if we force the developer to write an annotation for each validation, in addition to the java code for the validation; we are adding bureaucratic work for the developer.

My suggestion is to include a built in constraint in JSR-303 called @Constraint, @Validator, @GenericConstraint or so, that can be used in this way:

Code:
@Validator(InvoiceConstraint.class)
public class Invoice {
   ...
}

Where InvoiceConstraint implements Constraint.

Because the validation logic for Invoice can be used only on Invoice, we do not need to define an annotation for it, only the class, therefore you will save a lot of bureaucratic code.
This is in the spirit of the @ProperyValidator
http://openxava.wikispaces.com/model_en#toc11
and @EntityValidator
http://openxava.wikispaces.com/model_en#toc19
annotations of OpenXava

What do you think ?


Top
 Profile  
 
 Post subject: nice idea
PostPosted: Fri Apr 18, 2008 10:09 am 
Beginner
Beginner

Joined: Thu Apr 17, 2008 5:47 pm
Posts: 26
Very good idea!

For example I have a domain model and a set of message classes (send/recv via JMS) and each message class contains an instance of the domain model part - a subgraph.
Every such message class should validate first that the subgraph structure it carries is valid, then it should validate each instance there.
So the validation of each message class (the subgraph structure) is applicable only for it and not usable anywhere else.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Apr 23, 2008 8:20 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
I don't see it as bureaucratic as it adds readability to the code base.

But nothing prevents you from writing such a generic annotation.

_________________
Emmanuel


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 24, 2008 2:03 pm 
Beginner
Beginner

Joined: Fri Jan 14, 2005 7:47 am
Posts: 37
Location: Spain
emmanuel wrote:
I don't see it as bureaucratic as it adds readability to the code base.

Writting more code for obtain the same result is not good. At least I don't like. Maybe I have write a lot of EJB code in my life. And now I'm very sensible to bureaucratic code.
I'm sure that if you would write an application with a different validation for each model class, with more than 50 model classes, at the end you will write for yourself this annotation.

emmanuel wrote:
But nothing prevents you from writing such a generic annotation.

It's already written, and it is a Hibernate Validator constraint, you can see it here:
http://www.gestion400.com/OpenXavaDoc/a ... dator.html

But, it's important to include it (or one alike) in JSR-303. When more build in annotations more portability of the model classes between frameworks.

Cheers


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 24, 2008 3:15 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
I ahve noted the point. Let's see how the EG like the idea

_________________
Emmanuel


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.