ok, je vois mieux.
En fait, le CompoundPropertyModel montre ici ses limites : le radioChoice nécessite en fait deux modèles, un pour la valeur sélectionnée et un pour la liste de valeurs. Or le compoundPropertyModel ne marche qu'avec l'identifiant du composant, d'où le soucis.
Ceci dit, fournir deux modèles est chose aisée, par exemple :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
| static class TestForm extends Form {
private String radioValue ;
private List<String> list = new ArrayList<String>();
public TestForm(String string) {
super(string);
list.add("valeur 1");
list.add("valeur 2");
radioValue = "valeur 3";
list.add(radioValue);
add(new FeedbackPanel("feedback"));
add(new RadioChoice<String>("radio",new PropertyModel<String>(this,"radioValue"),new PropertyModel<List<String>>(this,"list")));
}
@Override
protected void onSubmit() {
System.out.println("current value " + radioValue);
}
} |
avec
1 2 3 4 5 6
| <form wicket:id="form">
<div wicket:id="feedback"></div>
<span wicket:id="radio">
</span>
<input type="submit"/>
</form> |
Dans ton cas, avec le CPM, et comme indiqué là : "working with wicket models" il est possible de binder directement depuis le modèle :
1 2 3 4
| CompoundPropertyModel personModel = new CompoundPropertyModel(person);
Form personForm = new Form("aPersonForm", personModel);
TextField cityField = new RequiredTextField("city", personModel.bind("address.city"));
personForm.add(cityField); |
soit au final (attention, pseudo code) :
add(new public RadioChoice("id", getModel().bind("valeurSelectionnee"), getModel().bind("listeDeChoixPossibles"));
nb : de façon générale, on adore au début le CompoundPropertyModel puis après on s'en lasse du fait de la nécessité de couplage entre le bean et les ids (contraignant en soi et, pour l'instant, non refactorisable).
Partager