The fact of the matter is that you will need extra logic _somewhere_. It's a matter of personal preference where you put it (overriden components, ajax, override form methods, ...).

If what you're trying to accomplish is difficult given a certain set of tools, my experience is that it's good to rethink the problem.

On the one hand you want isolation (components can have logic to say if they are required), and on the other hand you want to break outside of this isolation (form needs to control required flag on components). Having this logic in two different places is error-prone (at least from my experience). So why not have a single point in your code where you deal with the required flags of these components?

Bas

----- Original Message ----- From: "Phil Housley" <[email protected]>
To: <[email protected]>
Sent: Tuesday, September 15, 2009 3:37 PM
Subject: Re: Selectively ignoring required fields


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 <[email protected]>:
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"
<[email protected]>
To: <[email protected]>
Sent: Tuesday, September 15, 2009 2:30 PM
Subject: Re: Selectively ignoring required fields


2009/9/15 Martin Makundi <[email protected]>:

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 <[email protected]>:

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: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



--
Phil Housley

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]





--
Phil Housley

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to