Ok, updating myself in this thread... :D
I think for this integration succeed, one important question must be
resolved:
Q) What kind of validation this integration will process ?
a) wicket's internal validation
b) hibernate validator validation
c) behavior (like ryan implemented)
I made this code yesterday and it ran ok:
class ValidateForm extends Form {
public ValidateForm() {
super("form");
setModel(new CompoundPropertyModel(new User()));
add(new TextField("name"));
add(new TextField("email"));
add(new HibernateFormValidator(User.class));
}
}
class HibernateFormValidator implements IFormValidator {
private ClassValidator validator;
public HibernateFormValidator(Class name) { validator = new
ClassValidator(name); }
public FormComponent[] getDependentFormComponents() { return null; }
public void validate(Form form) {
Object object = form.getModelObject();
InvalidValue[] invalidValues = validator.getInvalidValues(object);
for (InvalidValue iv : invalidValues) form.error(iv.getMessage());
}
}
This is an example if we choose option b. And Ryan's option c we have
already seen.
Imho, IFormValidator really should be used as a Form validation. :)
About client-side, this is much more critical 'cause IValidator is quite
generic (as Igor said before). I think IJavascriptValidator would be the
best approach, as we need *javascript code somewhere in the client-side.
Another thing: IJavascriptValidator can be used also in server-side as well,
and still be generic (been used in service layer) if the programmer eval
this validator with some API that runs Scripting Language - JSR
223<http://jcp.org/en/jsr/detail?id=223>.
So, one implementation only (in javascript) been evaluated at client and
server side. :) Of course, this shouldn't be required and the unique option
to IValidators, but I think is the best approach.
Any thoughts?
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/9/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
From my earlier email:
> To do that, we have a couple of things to tackle:
>
> 1) Validators are currently server side all-the-way. But they don't
> have to be imho. If you combine a behavior and validator, you can
> create a validator that checks on the server side (imo, *always* do
> that, even if you have the client side covered well) and additionally
> write out some client side validation script.
So, it's not directly related to solving hiberate validation
integration, but I think this is a good time to look at how we can
improve validation overall. Also, you were already adding a behavior,
and this triggered me to look for a more generic solution. Doesn't
have to let you hold back though. I think I can commit something in a
few hours. Then if you want, Bruno and you can decide to pick this up
or not.
The second point I was making is more useful for this case. You need
enough tools to introspect on models for your validation needs. Like I
said before, I don't think I agree with using a behavior for
validation. It might work well, especialy as the behavior(s) can add
additional validators etc, but compared to just having one validator
(on the form, which is the main case I'm thinking about), it's a lot
more state for the same result.
Eelco
On 5/9/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
> I'm a little confused on how these changes would impact the hibernate
> integration. anyone care to spell out how this changes the code?
>
> On 5/9/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > Sounds good to me.
> >
> > Eelco
> >
> > On 5/9/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > what about making iformvalidator extend ivalidator. and
ibehaviorprovider
> > > extend ivalidator.
> > >
> > > in formvalidator validatable.value can be form.modelobject() and
> > > validatable.error reports an error on form.
> > >
> > > -igor
> > >
> > >
> > > On 5/9/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > no. dont forget that the idea of IValidator is to be decoupled
from
> > > > wicket,
> > > > > to allow the reuse of validators in service layer. i do that all
the
> > > > time
> > > > > now and it rocks! my service layer and my ui layer are validated
by the
> > > > same
> > > > > code. adding ivalidator.getbehavior() will break all that nice
> > > > decoupling.
> > > > >
> > > > > i always thought that something like this would work
> > > > >
> > > > > IClientSideValidator extends IValidator { /** rerturn a js func
to
> > > > validate
> > > > > the value */ CharSequence getValidationScript(); }
> > > >
> > > > /**
> > > > * Validator that provides a behavior, e.g. for rendering
client-side or
> > > > ajax
> > > > * validation. This interface can be implemented by either
> > > > * [EMAIL PROTECTED] IValidator validators} or [EMAIL PROTECTED]
IFormValidator form
validators}.
> > > > */
> > > > public interface IBehaviorProvider extends IClusterable
> > > > {
> > > > /**
> > > > * Gets behavior for validation.
> > > > *
> > > > * @param component
> > > > * component currently using the validator
> > > > * @return The behavior, which can be used for rendering
e.g.
> > > > */
> > > > IBehavior getValidationBehavior(Component component);
> > > > }
> > > >
> > > > same here, instanceof check and ready. Not extra code as how to
> > > > interpret it, and all the flexibility that behaviors provide.
> > > >
> > > > Eelco
> > > >
> > >
> >
>
