I'd say what's reccomended to do in that case is to use a FormValidator in
order to check the conditions that make the toggling component validatable
or not. Check those conditions on the other component's input (getInput(),
getConvertedInput()), because model objects won't be updated until
validation phase ends.
I've been struggling recently on this matter with components inside
refreshingviews, and I have to say I'm feeling like not doing things the way
they should be, i'll append a sample of the formvalidator. I have the
refreshingview as a class attribute, altough it could have been found by
calling a visitor on the Form parameter of validate(), and using a 'tagging'
subclass for the refreshingview. I'd appreciate any comments on this code,
and if it can be improved in any way, I'd love to follow your suggestions
(also, hope that helps, Iain :) )
It's a validator that need counting how many inputs have been filled by the
user to make some business validation. I've been making 'tagging' subclasses
(no code by themselves, only super constructors) of the components inside
the view just to write a simpler visitor:
new IFormValidator(){
private static final long serialVersionUID = 1L;
public FormComponent[] getDependentFormComponents() { return
null; }
public void validate(Form form) {
List<IModel> beansList =
(List<IModel>)refreshingView.getModelObject();
// Check count for some inputs on the view
countInputsA= 0;
countInputsB = 0;
// Obtenir els components de desplegables per consultar
inputs en cas que toqui
final List<FormComponent> typeAComponents = new
ArrayList<FormComponent>();
final List<FormComponent> typeBComponents= new
ArrayList<FormComponent>();
refreshingView.visitChildren(TypeAComponent.class, new
IVisitor(){
public Object component(Component component) {
typeAComponents.add((FormComponent)component);
return CONTINUE_TRAVERSAL;
}
});
refreshingView.visitChildren(DdcEntrevistaM45DropDownChoice.class, new
IVisitor(){
public Object component(Component component) {
typeBComponents.add((FormComponent)component);
return CONTINUE_TRAVERSAL;
}
});
for (FormComponent component : typeAComponents ) {
if (component.getConvertedInput() != null){
countInputsA++;
}
}
for (FormComponent component : typeBComponents ) {
if (component.getConvertedInput() != null){
countInputsB++;
}
}
// perform some validations on countInputsA and countInputsB
if (countInputsA > countInputsB) {
error("whatever");
}
}
2010/6/1 Iain Reddick <iain.redd...@beatsystems.com>
> With (2) and (3), what is the best way of handling validation?
>
> With (1), the server-side state for the form is correct, and the hidden
> component won't be validated on form submit.
>
> With (2) and (3), the "visible" state of the toggled component is purely
> client side. This means that on form submit, the hidden component will still
> be validated.
>
>
> Pedro Santos wrote:
>
>> 2 or 3 since there is no relevant state on the server side you want to
>> consider to implement the component visibility rule.
>>
>> On Tue, Jun 1, 2010 at 7:37 AM, Iain Reddick
>> <iain.redd...@beatsystems.com>wrote:
>>
>>
>>
>>> Say I have a form with a check box that, when checked, shows some other
>>> field (i.e. it controls the visibility of other form components).
>>>
>>> What is the best approach to handling this?
>>>
>>> From what I understand, you have 3 options:
>>>
>>> 1. Add ajax behaviour to the check box (re-render relevant components).
>>> 2. Add javascript from the Java code (e.g. add some kind of show/hide
>>> behaviour).
>>> 3. Add javascript directly to the HTML.
>>>
>>> What are peoples experiences of the 3 methods, and which is best?
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
