Maybe you should turn your enforcements to the framework hot spots.
>>> (+) search by X
>>> a: [_____]
>>> b: [_____]
>>>
>>> () search by Y
>>> ...
>>>
>>> () search by Z
Each group of options is its own panel
You can create an validation with those conditions, and add only on
necessary fiels.
Ex:
private class NotNullWhenGroupSelected implements IValidator{
private FormComponent formComponent;
private Model radioButtonModel;
public void validate(IValidatable validatable) {
if(radioButtonModel.getObject().isValidationMandatoryTo(formComponent){
if(validatable.getValue() == null){
validatable.error(new IValidationError());
}
}
}
}
On Tue, Sep 15, 2009 at 10:37 AM, Phil Housley <undeconstruc...@gmail.com>wrote:
> Several interesting ideas, but they all seem to involve more invasive
> changes than I really want to make - either changing component classes
> or changing values of components at process time, which would be hard
> to undo (and maybe not possible, as some components already have logic
> to say if they are required.)
>
> From hunting through the code, what would be about perfect would be to
> override org.apache.wicket.markup.html.form.Form#validateComponents(),
> but unfortunately that is final. Even if I were to copy some of the
> code into my form class, there are some private methods of Form that I
> would need to call.
>
> Has anyone perhaps had a similar issue somewhere else?
>
> Thanks again,
>
> Phil.
>
> 2009/9/15 Bas Gooren <b...@iswd.nl>:
> > Phil,
> >
> > The way we deal with this is by using an ajax behavior on radiobuttons,
> and
> > update the required flag on dependant fields from there.
> >
> > Another way (without ajax) could be to update the required flag on the
> form
> > components on submit, prior to validation.
> > E.g. by overriding Form.process() (or Form.validate(), since this is
> related
> > to validation).
> >
> > E.g. something like
> >
> > Form form = new Form( "id", ... ) {
> > protected void validate() {
> > // Update required flags on fields
> > // ...
> >
> > // Call regular validation
> > super.validate();
> > }
> > }
> >
> > Regards,
> >
> > Bas
> >
> > ----- Original Message ----- From: "Phil Housley"
> > <undeconstruc...@gmail.com>
> > To: <users@wicket.apache.org>
> > Sent: Tuesday, September 15, 2009 2:30 PM
> > Subject: Re: Selectively ignoring required fields
> >
> >
> > 2009/9/15 Martin Makundi <martin.maku...@koodaripalvelut.com>:
> >>
> >> You can override isRequired for any component.
> >>
> >> **
> >> Martin
> >>
> >
> > Thanks, but I really don't want to have to make the individual fields
> > context aware unless I have to. We have quite a few custom form
> > controls, which are used both in searching and various other places,
> > so it would be a lot of work to make them all respond to this
> > particular use. A way to just prevent the required check/validation
> > from the top would fit the bill better.
> >
> >> 2009/9/15 Phil Housley <undeconstruc...@gmail.com>:
> >>>
> >>> Hello,
> >>>
> >>> I'm currently working on a search interface, where the required-ness
> >>> of some fields depends on the value of some other. In particular, the
> >>> form looks something like
> >>>
> >>> (+) search by X
> >>> a: [_____]
> >>> b: [_____]
> >>>
> >>> () search by Y
> >>> ...
> >>>
> >>> () search by Z
> >>> ...
> >>>
> >>> So the radio button selects a group of fields, in which any number may
> >>> be required. Each group of options is its own panel, and basically
> >>> independent. Is it possible for me to ignore protests from the fields
> >>> in sections Y and Z, after reading the input from the radio button?
> >>> Ideally I'd like to record the values from every field, and keep it
> >>> around as raw input, but I don't want to know if it is missing or
> >>> fails to convert/validate.
> >>>
> >>> Thanks for any help.
> >>>
> >>> --
> >>> Phil Housley
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
> >
> > --
> > Phil Housley
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>
>
>
> --
> Phil Housley
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
