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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>
> ---------------------------------------------------------------------
> 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
