Re: Show/hide form components best practice
Please correct me if I'm wrong, but, once the component's validators have
been passed, and when executing, for instance a FormValidator, you can get
the converted input of the Checkbox. Then choose to use or not the input of
the conditional field. Of course that prevents you from using setRequired on
that field, because it would be executed as a Component Validator before the
Form one.
Hope that helps,
Xavier
2010/6/16 Iain Reddick iain.redd...@beatsystems.com
I looked at this again today and realised that my examples are basically
broken (also typos in the last one :) ).
Obviously, you can't use the converted input of a FormComponent before
validation has happened. This means that using the CheckBox converted input
to determine whether another form component is used in the submission is
wrong - it will only return the value it held before the submit. You would
actually have to look at the raw input.
So I'm back at square one with this again.
I suppose my question is Is component visibility the only means of
determining whether a form component should be considered in the form submit
mechanism?.
- Original Message -
From: Iain Reddick iain.redd...@beatsystems.com
To: users@wicket.apache.org
Sent: Wednesday, 9 June, 2010 8:35:13 PM
Subject: Re: Show/hide form components best practice
Looking at the wicket source regarding this, I don't think it's possible
to get the desired behaviour.
It looks like a new hook is needed in FormComponent.validate() that is
called before any of the other logic.
Something like FormComponent.isUsed(). If this returns false, just exit
the validate() methods.
Default FormComponent implementation would return true for this method,
but it can be overriden to provide the desired behaviour.
As I understand the submit/validate/bind sequence, this would mean that
the form component's raw input is updated (which makes sense), but
validation/model object doesn't happen.
Is this feasible, and would it impact elsewhere?
Here's an update of my previous example showing how it would be used:
private class TestForm extends Form {
private String always;
private boolean useOptional = false;
private String optional;
public TestForm(String id) {
super(id);
add( new TextField(always, new PropertyModel(this,
always)).setRequired(true) );
final CheckBox useOptionalCheck = new CheckBox( useOptional, new
PropertyModel(this, useOptional) );
add( useOptionalCheck );
add( new TextField(optional, new PropertyModel(this, optional)) {
@Override public boolean isUsed() {
return ((Boolean)useOptionalCheck.getConvertedInput()).booleanValue();
}
@Override
public boolean isRequired() {
isUsed(); }
}.add(MinimumLengthValidator.minimumLength(3)) );
}
}
- Original Message -
From: Xavier López xavil...@gmail.com
To: users@wicket.apache.org
Sent: Thursday, 3 June, 2010 2:56:33 PM
Subject: Re: Show/hide form components best practice
I'm with you on this one, this code feels like doing something that it
shouldn't, looks kind of bloated for such a simple and common
requirement. Maybe we need some stuffing of nice, pre-canned
FormValidators ? :)
The problem with wicket's validators, as I see it, is that they are at a
Component level. They do their job based on that component's
input/state, only. In fact, they are called in Form's
validateComponents() one by one in
a traversal. If another component's input or state is required to
perform the validation, i'd do it inside a FormValidator. That copes
with your
requirement of ignore the input for this component completely,
although I
don't know how would that be achieved.
Of course, in all those comments, I assume you can not rely on
javascript nor ajax to perform those validations, in which case the
visibility approach
simply couldn't work.
Cheers,
Xavier
2010/6/3 Iain Reddick iain.redd...@beatsystems.com
The problem with this approach is that you throw away all the nice,
re-usable pre-canned validators that wicket has, and that it seems
very wrong.
I'd actually push the behaviour I would like to see even further - in
the example I gave, I don't even want the optional field to update
it's model
when the check box isn't selected.
Effectively, I want to be able to specify logic which says ignore the
input for this component completely. Currently, the only way to do
this is
by using component visibility (unless I'm completely wrong on this).
Xavier López wrote:
Hi Iain,
I would do it like this, with a FormValidator. I moved the minimum
length validation also to the formValidator, because doing it with a
MinimumLenghtValidator would trigger it before the formValidator
executes, and may raise errors when the input is not valid (i.e. not
mandatory) :
private class TestForm extends Form {
IModel modelAlways;
IModel modelCheckOptional;
IModel modelOptional;
public TestForm(String id) {
super(id
Re: Show/hide form components best practice
I looked at this again today and realised that my examples are basically broken
(also typos in the last one :) ).
Obviously, you can't use the converted input of a FormComponent before
validation has happened. This means that using the CheckBox converted input to
determine whether another form component is used in the submission is wrong -
it will only return the value it held before the submit. You would actually
have to look at the raw input.
So I'm back at square one with this again.
I suppose my question is Is component visibility the only means of determining
whether a form component should be considered in the form submit mechanism?.
- Original Message -
From: Iain Reddick iain.redd...@beatsystems.com
To: users@wicket.apache.org
Sent: Wednesday, 9 June, 2010 8:35:13 PM
Subject: Re: Show/hide form components best practice
Looking at the wicket source regarding this, I don't think it's possible
to get the desired behaviour.
It looks like a new hook is needed in FormComponent.validate() that is
called before any of the other logic.
Something like FormComponent.isUsed(). If this returns false, just exit
the validate() methods.
Default FormComponent implementation would return true for this method,
but it can be overriden to provide the desired behaviour.
As I understand the submit/validate/bind sequence, this would mean that
the form component's raw input is updated (which makes sense), but
validation/model object doesn't happen.
Is this feasible, and would it impact elsewhere?
Here's an update of my previous example showing how it would be used:
private class TestForm extends Form {
private String always;
private boolean useOptional = false;
private String optional;
public TestForm(String id) {
super(id);
add( new TextField(always, new PropertyModel(this,
always)).setRequired(true) );
final CheckBox useOptionalCheck = new CheckBox( useOptional, new
PropertyModel(this, useOptional) );
add( useOptionalCheck );
add( new TextField(optional, new PropertyModel(this, optional)) {
@Override public boolean isUsed() {
return ((Boolean)useOptionalCheck.getConvertedInput()).booleanValue();
}
@Override
public boolean isRequired() {
isUsed(); }
}.add(MinimumLengthValidator.minimumLength(3)) );
}
}
- Original Message -
From: Xavier López xavil...@gmail.com
To: users@wicket.apache.org
Sent: Thursday, 3 June, 2010 2:56:33 PM
Subject: Re: Show/hide form components best practice
I'm with you on this one, this code feels like doing something that it
shouldn't, looks kind of bloated for such a simple and common
requirement. Maybe we need some stuffing of nice, pre-canned
FormValidators ? :)
The problem with wicket's validators, as I see it, is that they are at a
Component level. They do their job based on that component's
input/state, only. In fact, they are called in Form's
validateComponents() one by one in
a traversal. If another component's input or state is required to
perform the validation, i'd do it inside a FormValidator. That copes
with your
requirement of ignore the input for this component completely,
although I
don't know how would that be achieved.
Of course, in all those comments, I assume you can not rely on
javascript nor ajax to perform those validations, in which case the
visibility approach
simply couldn't work.
Cheers,
Xavier
2010/6/3 Iain Reddick iain.redd...@beatsystems.com
The problem with this approach is that you throw away all the nice,
re-usable pre-canned validators that wicket has, and that it seems
very wrong.
I'd actually push the behaviour I would like to see even further - in
the example I gave, I don't even want the optional field to update
it's model
when the check box isn't selected.
Effectively, I want to be able to specify logic which says ignore the
input for this component completely. Currently, the only way to do
this is
by using component visibility (unless I'm completely wrong on this).
Xavier López wrote:
Hi Iain,
I would do it like this, with a FormValidator. I moved the minimum
length validation also to the formValidator, because doing it with a
MinimumLenghtValidator would trigger it before the formValidator
executes, and may raise errors when the input is not valid (i.e. not
mandatory) :
private class TestForm extends Form {
IModel modelAlways;
IModel modelCheckOptional;
IModel modelOptional;
public TestForm(String id) {
super(id);
modelAlways = new Model();
modelCheckOptional = Boolean.FALSE;
modelOptional = new Model();
final TextField alwaysTextfield = new TextField(always,
modelAlways); alwaysTextField.setRequired(true);
add(alwaysTextField); final CheckBox useOptionalCheck = new
CheckBox( useOptional,
modelCheckOptional);
add( useOptionalCheck );
final TextField optionalTextField = new TextField(optional,
modelOptional);
add(optionalTextField);
add(new IFormValidator(){
protected FormComponent getDependentFormComponents(){ return
null
Re: Show/hide form components best practice
Looking at the wicket source regarding this, I don't think it's possible to get
the desired behaviour.
It looks like a new hook is needed in FormComponent.validate() that is called
before any of the other logic.
Something like FormComponent.isUsed(). If this returns false, just exit the
validate() methods.
Default FormComponent implementation would return true for this method, but it
can be overriden to provide the desired behaviour.
As I understand the submit/validate/bind sequence, this would mean that the
form component's raw input is updated (which makes sense), but validation/model
object doesn't happen.
Is this feasible, and would it impact elsewhere?
Here's an update of my previous example showing how it would be used:
private class TestForm extends Form {
private String always;
private boolean useOptional = false;
private String optional;
public TestForm(String id) {
super(id);
add( new TextField(always, new PropertyModel(this,
always)).setRequired(true) );
final CheckBox useOptionalCheck = new CheckBox( useOptional, new
PropertyModel(this, useOptional) );
add( useOptionalCheck );
add( new TextField(optional, new PropertyModel(this, optional)) {
@Override
public boolean isUsed() {
return ((Boolean)useOptionalCheck.getConvertedInput()).booleanValue();
}
@Override
public boolean isRequired() {
isUsed();
}
}.add(MinimumLengthValidator.minimumLength(3)) );
}
}
- Original Message -
From: Xavier López xavil...@gmail.com
To: users@wicket.apache.org
Sent: Thursday, 3 June, 2010 2:56:33 PM
Subject: Re: Show/hide form components best practice
I'm with you on this one, this code feels like doing something that it
shouldn't, looks kind of bloated for such a simple and common
requirement. Maybe we need some stuffing of nice, pre-canned
FormValidators ? :)
The problem with wicket's validators, as I see it, is that they are at a
Component level. They do their job based on that component's
input/state, only. In fact, they are called in Form's
validateComponents() one by one in
a traversal. If another component's input or state is required to
perform the validation, i'd do it inside a FormValidator. That copes
with your
requirement of ignore the input for this component completely,
although I
don't know how would that be achieved.
Of course, in all those comments, I assume you can not rely on
javascript nor ajax to perform those validations, in which case the
visibility approach
simply couldn't work.
Cheers,
Xavier
2010/6/3 Iain Reddick iain.redd...@beatsystems.com
The problem with this approach is that you throw away all the nice,
re-usable pre-canned validators that wicket has, and that it seems
very wrong.
I'd actually push the behaviour I would like to see even further - in
the example I gave, I don't even want the optional field to update
it's model
when the check box isn't selected.
Effectively, I want to be able to specify logic which says ignore the
input for this component completely. Currently, the only way to do
this is
by using component visibility (unless I'm completely wrong on this).
Xavier López wrote:
Hi Iain,
I would do it like this, with a FormValidator. I moved the minimum
length validation also to the formValidator, because doing it with a
MinimumLenghtValidator would trigger it before the formValidator
executes, and may raise errors when the input is not valid (i.e. not
mandatory) :
private class TestForm extends Form {
IModel modelAlways;
IModel modelCheckOptional;
IModel modelOptional;
public TestForm(String id) {
super(id);
modelAlways = new Model();
modelCheckOptional = Boolean.FALSE;
modelOptional = new Model();
final TextField alwaysTextfield = new TextField(always,
modelAlways); alwaysTextField.setRequired(true);
add(alwaysTextField); final CheckBox useOptionalCheck = new
CheckBox( useOptional,
modelCheckOptional);
add( useOptionalCheck );
final TextField optionalTextField = new TextField(optional,
modelOptional);
add(optionalTextField);
add(new IFormValidator(){
protected FormComponent getDependentFormComponents(){ return
null; }
public boolean validate(Form f){
if
(Boolean.TRUE.equals(useOptionalCheck.getConvertedInput()){
String optionalValue =
optionalTextField.getConvertedInput();
if (Strings.isEmpty(optionalValue ){
error (field optional is required);
} else if (optionalValue.length 3){
error (optional value's length must be at
least 3);
}
}.
} });
Cheers,
Xavier
2010/6/2 Iain Reddick iain.redd...@beatsystems.com
Here's some example code (wicket 1.3.x):
Java:
private class TestForm extends Form {
private String always;
private boolean useOptional = false;
private String optional
Re: Show/hide form components best practice
Hi Iain,
I would do it like this, with a FormValidator. I moved the minimum length
validation also to the formValidator, because doing it with a
MinimumLenghtValidator would trigger it before the formValidator executes,
and may raise errors when the input is not valid (i.e. not mandatory) :
private class TestForm extends Form {
IModel modelAlways;
IModel modelCheckOptional;
IModel modelOptional;
public TestForm(String id) {
super(id);
modelAlways = new Model();
modelCheckOptional = Boolean.FALSE;
modelOptional = new Model();
final TextField alwaysTextfield = new TextField(always, modelAlways);
alwaysTextField.setRequired(true);
add(alwaysTextField);
final CheckBox useOptionalCheck = new CheckBox( useOptional,
modelCheckOptional);
add( useOptionalCheck );
final TextField optionalTextField = new TextField(optional,
modelOptional);
add(optionalTextField);
add(new IFormValidator(){
protected FormComponent getDependentFormComponents(){ return null; }
public boolean validate(Form f){
if (Boolean.TRUE.equals(useOptionalCheck.getConvertedInput()){
String optionalValue =
optionalTextField.getConvertedInput();
if (Strings.isEmpty(optionalValue ){
error (field optional is required);
}
else if (optionalValue.length 3){
error (optional value's length must be at least 3);
}
}.
}
});
Cheers,
Xavier
2010/6/2 Iain Reddick iain.redd...@beatsystems.com
Here's some example code (wicket 1.3.x):
Java:
private class TestForm extends Form {
private String always;
private boolean useOptional = false;
private String optional;
public TestForm(String id) {
super(id);
add( new TextField(always, new PropertyModel(this,
always)).setRequired(true) );
final CheckBox useOptionalCheck = new CheckBox( useOptional, new
PropertyModel(this, useOptional) );
add( useOptionalCheck );
add( new TextField(optional, new PropertyModel(this, optional)) {
@Override
public boolean isRequired() {
return
((Boolean)useOptionalCheck.getConvertedInput()).booleanValue();
}
}.add(MinimumLengthValidator.minimumLength(3)) );
}
}
Markup:
form wicket:id=testForm
input wicket:id=always type=text /
input wicket:id=useOptional type=checkbox /
input wicket:id=optional type=text /
input type=submit /
/form
How can I express that I want the optional text field to only be used when
the checkbox is selected?
- Original Message -
From: Igor Vaynberg igor.vaynb...@gmail.com
To: users@wicket.apache.org
Sent: Wednesday, 2 June, 2010 4:00:57 PM
Subject: Re: Show/hide form components best practice
if the form contains all the state then the answer is simple: write a
bit of javascript that does it for you.
-igor
On Wed, Jun 2, 2010 at 2:53 AM, Iain Reddick
iain.redd...@beatsystems.com wrote:
That's just a server round-trip on client-side state changem, which is
basically (1) in my initial list.
Basically, this type of form behaviour is very common and the question
of how to implement it with Wicket has been raised by every developer
I know
who has worked with the framework.
I know that Wicket generally works best when you round-trip
client-side state changes to the server, but I think that in this
situation it is silly,
as the submitted form contains all the required state.
Jeremy Thomerson wrote:
return true from wantOnSelectionChangedNotifications and put your
visibility changing code in onSelectionChanged
http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications()http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications%28%29
http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications()http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications%28%29
On Tue, Jun 1, 2010 at 5:37 AM, Iain Reddick
iain.redd...@beatsystems.comwrote:
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
Re: Show/hide form components best practice
The problem with this approach is that you throw away all the nice,
re-usable pre-canned validators that wicket has, and that it seems very
wrong.
I'd actually push the behaviour I would like to see even further - in
the example I gave, I don't even want the optional field to update it's
model when the check box isn't selected.
Effectively, I want to be able to specify logic which says ignore the
input for this component completely. Currently, the only way to do this
is by using component visibility (unless I'm completely wrong on this).
Xavier López wrote:
Hi Iain,
I would do it like this, with a FormValidator. I moved the minimum length
validation also to the formValidator, because doing it with a
MinimumLenghtValidator would trigger it before the formValidator executes,
and may raise errors when the input is not valid (i.e. not mandatory) :
private class TestForm extends Form {
IModel modelAlways;
IModel modelCheckOptional;
IModel modelOptional;
public TestForm(String id) {
super(id);
modelAlways = new Model();
modelCheckOptional = Boolean.FALSE;
modelOptional = new Model();
final TextField alwaysTextfield = new TextField(always, modelAlways);
alwaysTextField.setRequired(true);
add(alwaysTextField);
final CheckBox useOptionalCheck = new CheckBox( useOptional,
modelCheckOptional);
add( useOptionalCheck );
final TextField optionalTextField = new TextField(optional,
modelOptional);
add(optionalTextField);
add(new IFormValidator(){
protected FormComponent getDependentFormComponents(){ return null; }
public boolean validate(Form f){
if (Boolean.TRUE.equals(useOptionalCheck.getConvertedInput()){
String optionalValue =
optionalTextField.getConvertedInput();
if (Strings.isEmpty(optionalValue ){
error (field optional is required);
}
else if (optionalValue.length 3){
error (optional value's length must be at least 3);
}
}.
}
});
Cheers,
Xavier
2010/6/2 Iain Reddick iain.redd...@beatsystems.com
Here's some example code (wicket 1.3.x):
Java:
private class TestForm extends Form {
private String always;
private boolean useOptional = false;
private String optional;
public TestForm(String id) {
super(id);
add( new TextField(always, new PropertyModel(this,
always)).setRequired(true) );
final CheckBox useOptionalCheck = new CheckBox( useOptional, new
PropertyModel(this, useOptional) );
add( useOptionalCheck );
add( new TextField(optional, new PropertyModel(this, optional)) {
@Override
public boolean isRequired() {
return
((Boolean)useOptionalCheck.getConvertedInput()).booleanValue();
}
}.add(MinimumLengthValidator.minimumLength(3)) );
}
}
Markup:
form wicket:id=testForm
input wicket:id=always type=text /
input wicket:id=useOptional type=checkbox /
input wicket:id=optional type=text /
input type=submit /
/form
How can I express that I want the optional text field to only be used when
the checkbox is selected?
- Original Message -
From: Igor Vaynberg igor.vaynb...@gmail.com
To: users@wicket.apache.org
Sent: Wednesday, 2 June, 2010 4:00:57 PM
Subject: Re: Show/hide form components best practice
if the form contains all the state then the answer is simple: write a
bit of javascript that does it for you.
-igor
On Wed, Jun 2, 2010 at 2:53 AM, Iain Reddick
iain.redd...@beatsystems.com wrote:
That's just a server round-trip on client-side state changem, which is
basically (1) in my initial list.
Basically, this type of form behaviour is very common and the question
of how to implement it with Wicket has been raised by every developer
I know
who has worked with the framework.
I know that Wicket generally works best when you round-trip
client-side state changes to the server, but I think that in this
situation it is silly,
as the submitted form contains all the required state.
Jeremy Thomerson wrote:
return true from wantOnSelectionChangedNotifications and put your
visibility changing code in onSelectionChanged
http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications()http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications%28%29
http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications()http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications%28%29
On Tue, Jun 1, 2010 at 5:37 AM, Iain Reddick
iain.redd...@beatsystems.comwrote:
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
Re: Show/hide form components best practice
I'm with you on this one, this code feels like doing something that it
shouldn't, looks kind of bloated for such a simple and common requirement.
Maybe we need some stuffing of nice, pre-canned FormValidators ? :)
The problem with wicket's validators, as I see it, is that they are at a
Component level. They do their job based on that component's input/state,
only. In fact, they are called in Form's validateComponents() one by one in
a traversal. If another component's input or state is required to perform
the validation, i'd do it inside a FormValidator. That copes with your
requirement of ignore the input for this component completely, although I
don't know how would that be achieved.
Of course, in all those comments, I assume you can not rely on javascript
nor ajax to perform those validations, in which case the visibility approach
simply couldn't work.
Cheers,
Xavier
2010/6/3 Iain Reddick iain.redd...@beatsystems.com
The problem with this approach is that you throw away all the nice,
re-usable pre-canned validators that wicket has, and that it seems very
wrong.
I'd actually push the behaviour I would like to see even further - in the
example I gave, I don't even want the optional field to update it's model
when the check box isn't selected.
Effectively, I want to be able to specify logic which says ignore the
input for this component completely. Currently, the only way to do this is
by using component visibility (unless I'm completely wrong on this).
Xavier López wrote:
Hi Iain,
I would do it like this, with a FormValidator. I moved the minimum length
validation also to the formValidator, because doing it with a
MinimumLenghtValidator would trigger it before the formValidator executes,
and may raise errors when the input is not valid (i.e. not mandatory) :
private class TestForm extends Form {
IModel modelAlways;
IModel modelCheckOptional;
IModel modelOptional;
public TestForm(String id) {
super(id);
modelAlways = new Model();
modelCheckOptional = Boolean.FALSE;
modelOptional = new Model();
final TextField alwaysTextfield = new TextField(always, modelAlways);
alwaysTextField.setRequired(true);
add(alwaysTextField);
final CheckBox useOptionalCheck = new CheckBox( useOptional,
modelCheckOptional);
add( useOptionalCheck );
final TextField optionalTextField = new TextField(optional,
modelOptional);
add(optionalTextField);
add(new IFormValidator(){
protected FormComponent getDependentFormComponents(){ return null; }
public boolean validate(Form f){
if (Boolean.TRUE.equals(useOptionalCheck.getConvertedInput()){
String optionalValue =
optionalTextField.getConvertedInput();
if (Strings.isEmpty(optionalValue ){
error (field optional is required);
}
else if (optionalValue.length 3){
error (optional value's length must be at least 3);
}
}.
}
});
Cheers,
Xavier
2010/6/2 Iain Reddick iain.redd...@beatsystems.com
Here's some example code (wicket 1.3.x):
Java:
private class TestForm extends Form {
private String always;
private boolean useOptional = false;
private String optional;
public TestForm(String id) {
super(id);
add( new TextField(always, new PropertyModel(this,
always)).setRequired(true) );
final CheckBox useOptionalCheck = new CheckBox( useOptional, new
PropertyModel(this, useOptional) );
add( useOptionalCheck );
add( new TextField(optional, new PropertyModel(this, optional)) {
@Override
public boolean isRequired() {
return
((Boolean)useOptionalCheck.getConvertedInput()).booleanValue();
}
}.add(MinimumLengthValidator.minimumLength(3)) );
}
}
Markup:
form wicket:id=testForm
input wicket:id=always type=text /
input wicket:id=useOptional type=checkbox /
input wicket:id=optional type=text /
input type=submit /
/form
How can I express that I want the optional text field to only be used
when
the checkbox is selected?
- Original Message -
From: Igor Vaynberg igor.vaynb...@gmail.com
To: users@wicket.apache.org
Sent: Wednesday, 2 June, 2010 4:00:57 PM
Subject: Re: Show/hide form components best practice
if the form contains all the state then the answer is simple: write a
bit of javascript that does it for you.
-igor
On Wed, Jun 2, 2010 at 2:53 AM, Iain Reddick
iain.redd...@beatsystems.com wrote:
That's just a server round-trip on client-side state changem, which is
basically (1) in my initial list.
Basically, this type of form behaviour is very common and the question
of how to implement it with Wicket has been raised by every developer
I know
who has worked with the framework.
I know that Wicket generally works best when you round-trip
client-side state changes to the server, but I think that in this
situation it is silly,
as the submitted form contains all
Re: Show/hide form components best practice
That's just a server round-trip on client-side state changem, which is basically (1) in my initial list. Basically, this type of form behaviour is very common and the question of how to implement it with Wicket has been raised by every developer I know who has worked with the framework. I know that Wicket generally works best when you round-trip client-side state changes to the server, but I think that in this situation it is silly, as the submitted form contains all the required state. Jeremy Thomerson wrote: return true from wantOnSelectionChangedNotifications and put your visibility changing code in onSelectionChanged http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications() http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications() On Tue, Jun 1, 2010 at 5:37 AM, Iain Reddick iain.redd...@beatsystems.comwrote: 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
Re: Show/hide form components best practice
if the form contains all the state then the answer is simple: write a bit of javascript that does it for you. -igor On Wed, Jun 2, 2010 at 2:53 AM, Iain Reddick iain.redd...@beatsystems.com wrote: That's just a server round-trip on client-side state changem, which is basically (1) in my initial list. Basically, this type of form behaviour is very common and the question of how to implement it with Wicket has been raised by every developer I know who has worked with the framework. I know that Wicket generally works best when you round-trip client-side state changes to the server, but I think that in this situation it is silly, as the submitted form contains all the required state. Jeremy Thomerson wrote: return true from wantOnSelectionChangedNotifications and put your visibility changing code in onSelectionChanged http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications() http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications() On Tue, Jun 1, 2010 at 5:37 AM, Iain Reddick iain.redd...@beatsystems.comwrote: 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
Re: Show/hide form components best practice
Here's some example code (wicket 1.3.x):
Java:
private class TestForm extends Form {
private String always;
private boolean useOptional = false;
private String optional;
public TestForm(String id) {
super(id);
add( new TextField(always, new PropertyModel(this,
always)).setRequired(true) );
final CheckBox useOptionalCheck = new CheckBox( useOptional, new
PropertyModel(this, useOptional) );
add( useOptionalCheck );
add( new TextField(optional, new PropertyModel(this, optional)) {
@Override
public boolean isRequired() {
return ((Boolean)useOptionalCheck.getConvertedInput()).booleanValue();
}
}.add(MinimumLengthValidator.minimumLength(3)) );
}
}
Markup:
form wicket:id=testForm
input wicket:id=always type=text /
input wicket:id=useOptional type=checkbox /
input wicket:id=optional type=text /
input type=submit /
/form
How can I express that I want the optional text field to only be used when the
checkbox is selected?
- Original Message -
From: Igor Vaynberg igor.vaynb...@gmail.com
To: users@wicket.apache.org
Sent: Wednesday, 2 June, 2010 4:00:57 PM
Subject: Re: Show/hide form components best practice
if the form contains all the state then the answer is simple: write a
bit of javascript that does it for you.
-igor
On Wed, Jun 2, 2010 at 2:53 AM, Iain Reddick
iain.redd...@beatsystems.com wrote:
That's just a server round-trip on client-side state changem, which is
basically (1) in my initial list.
Basically, this type of form behaviour is very common and the question
of how to implement it with Wicket has been raised by every developer
I know
who has worked with the framework.
I know that Wicket generally works best when you round-trip
client-side state changes to the server, but I think that in this
situation it is silly,
as the submitted form contains all the required state.
Jeremy Thomerson wrote:
return true from wantOnSelectionChangedNotifications and put your
visibility changing code in onSelectionChanged
http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications()
http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications()
On Tue, Jun 1, 2010 at 5:37 AM, Iain Reddick
iain.redd...@beatsystems.comwrote:
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Show/hide form components best practice
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
Re: Show/hide form components best practice
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.comwrote: 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 -- Pedro Henrique Oliveira dos Santos
Re: Show/hide form components best practice
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.comwrote: 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
Re: Show/hide form components best practice
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) {
ListIModel beansList =
(ListIModel)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 ListFormComponent typeAComponents = new
ArrayListFormComponent();
final ListFormComponent typeBComponents= new
ArrayListFormComponent();
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.comwrote:
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
Re: Show/hide form components best practice
return true from wantOnSelectionChangedNotifications and put your visibility changing code in onSelectionChanged http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications() http://wicket.apache.org/docs/1.4/org/apache/wicket/markup/html/form/CheckGroup.html#wantOnSelectionChangedNotifications() On Tue, Jun 1, 2010 at 5:37 AM, Iain Reddick iain.redd...@beatsystems.comwrote: 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 -- Jeremy Thomerson http://www.wickettraining.com
