I'm bringing up my old thread here, as I found something that works
well enough, and it might help someone to have it in the list
archive.)
2009/9/15 Pedro Santos <pedros...@gmail.com>:
> On the other hand, maybe that whole criteria panel is deselected, in
> which case I want to be able to stop the whole thing from doing any
> validation at all, so it won't even look at whether the check box is
> checked.
>
> disable panel don't work on that case?
Just overriding isEnabled didn't do the trick by itself, but I found a
rather nasty little hack. The issue is that the individual panels
need to always be enabled for rendering, but only selectively enabled
at processing. Also, the decision about which panel to enable is
based on incoming data, which isn't always ready when needed. A
solution is to have each panel check whether it is enabled, by calling
up to the parent panel. The parent does this:
public boolean isItMyTurn(Criteria panel) {
if (this.rendering) {
return true;
} else {
this.radios.inputChanged();
int index = Integer.parseInt(this.radios.getRawInput());
Criteria active = this.panels.get(index);
if (active == panel) {
return true;
}
}
return false;
}
Where "rendering" is set in before and after render methods, and the
radio buttons are partially processed out of sequence to get the input
when its needed.
I don't know how safe this is, but it seems to work.
Thanks everyone.
> On Tue, Sep 15, 2009 at 11:10 AM, Phil Housley
> <undeconstruc...@gmail.com>wrote:
>
>> 2009/9/15 Bas Gooren <b...@iswd.nl>:
>> > 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
>>
>> A good point, but I don't think it exactly applies in this case. What
>> I really want is for each component to know whether it is required
>> within a very small context. For example, a might have a criteria
>> panel (one of the sub-parts of the searcher) set out as follows:
>>
>> [x] must be a foo called [_____]
>>
>> In which case, the sub panel will be in total charge of whether the
>> text field is required.
>>
>> On the other hand, maybe that whole criteria panel is deselected, in
>> which case I want to be able to stop the whole thing from doing any
>> validation at all, so it won't even look at whether the check box is
>> checked.
>>
>> What I am thinking currently is to sadly discard the built in
>> validation, and have each criteria panel report its errors manually
>> when asked to by the parent to pass on its generated set of criteria
>> (a map basically), which it has built out of its input. I don't like
>> it at all, as it lets bad data get too far into the system, but I
>> think it will solve the immediate problem.
>>
>> Phil.
>>
>> > ----- Original Message ----- From: "Phil Housley"
>> > <undeconstruc...@gmail.com>
>> > To: <users@wicket.apache.org>
>> > 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 <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
