If I write a field level custom validator how do I get access to the associated entity?

I could write a class level validator/annotation but then I would have to add back which field it relates to and it would make it harder to re-use.

Guess what I was expecting to see was a second argument to Validator.isValid which is the entity that the value belongs to.

So Validator.isValid(Object properyValue, Object entity) would seem handy.

Sorry if I'm missing something obvious

Cheers

Sam

Hi,


But the second parameter would be useless if the validator can't be tightly coupled to your bean, so you won't get it much reusable.

If you have a great use case or scenario, I would suggest you to look at the other forum: http://forum.hibernate.org/viewforum.php?f=26. There you can get the draft for next-gen Bean Validation, read the specs and post your suggestions for this kind of API changes.

regards,
Sanne

Thanks Sanne,

A unique constraint is the most compelling use case I have but as you say it does mean the validator needs to know something about the entity. I guess it could ask the hibernate core if it knows how to get the id for the object.

Anyway, think I'm going to have a big class level validator that checks unique username and that the email is from the correct set of domains.

Cheers

Sam

Hello,
probably the most efficient way to define a unique contraint is to delegate this sort of checks to the database, using or
In this way you don't need to make a secondary query the see if other entities exist, and DB integrity is ensured.

This doesn't solve your problem if you want to give immediate feedback to user though; if you are using this in a seam form to immediately inform to users the username is not available it wouldn't work;
in that case you probably want an entity validator which hits the database to check, and customize the message; I don't know how to bind the message to the correct field though.
To bind the value to the correct field I would define a validator bound to the single field, and use it only for the username of this entity: the validator would receive the proposed value and you may check on DB to see if it is available (you don't need the entity for this, and you know the class type). So you are not making a reusable validator, but it keeps things simple.

Be aware that the latter solution generates a database hit each time a user types something in the field.. you may want to avoid this type of ajax validation when not strictly required by your specs.

regards,
Sanne

The best I've come up with so far is to use a naming convention and @AssertTrue so something like:


Is then easy to just strip off "XValid" when working out which property the user needs to look at. Also much less hassle than writing a custom validator.

So not pretty but simple and works.

Cheers

Sam[/code]