Article complet: [Wicket] Ajouter des labels sans s'embêter...

Salut

Les Behavior wicket sont parfois un peu obscurs, aussi je vous propose d'en voir une application. L'idée est que le "label for" d'un élément soit ajouté à la volée, afin qu'on ait plus à le gérer tant dans l'html que côté Java.

[Suite:]

Comme d'habitude, c'est tout simple.

En effet, les Behavior permettent d'ajouter du texte dans notre page html avant et après les composants, via les méthodes beforeRender(Component component) et onRendered(Component component).

En l'occurrence, voici le Behavior créé :
 
public class AddLabelBehavior extends AbstractBehavior 
{ 
  @Override 
  public void beforeRender(Component component) 
  { 
  super.beforeRender(component); 
  StringBuilder addedLabel = new StringBuilder("<label for=\""); 
  addedLabel.append(component.setOutputMarkupId(true).getMarkupId()); 
  addedLabel.append("\" >"); 
  addedLabel.append((new StringResourceModel(component.getId(), component, null, component.getId()).getString())) 
  .append(" : </label>"); 
  component.getResponse().write(addedLabel); 
  } 
 
}

Petite explication de texte, du moins pour ce qui me semble non évident :
- j'étends AbstractBehavior. Ce dernier s'occupe de toute la plomberie pour mon behavior personnalisé. Je ne change que ce dont j'ai besoin, c'est à dire écrire quelque chose avant mon élément
- getResponse().write() permet tout simplement d'ajouter du texte dans l'html généré. Vu qu'on est dans le beforeRender, il s'ajoute avant l'élément décoré.
- le label for a besoin de l'id du composant, je dis donc à Wicket de l'afficher, via setOutputMarkupId(true) - on parle là bien de l'id au sens html du terme - puis je le récupère via le getMarkupId(). Wicket garantit alors l'unicité de cet id, je n'ai donc pas à me soucier d'éventuelle collision de noms. Cela aurait été le cas si j'avais défini moi même l'id, via un setMarkupId("monID"), surtout dans le cas de listes.
- le StringResourceModel me permet de rechercher la traduction du composant via son id (au sens Wicket du terme cette fois). J'ajoute aussi une valeur par défaut, correspondant au dernier paramètre du constructeur. Ainsi, si l'id de l'élément ne se trouve pas dans un fichier de propriété, on affichera son nom. C'est toujours mieux que rien !
- enfin, j'utilise bien sûr StringBuilder et non String tout court : ce Behavior sera souvent appelé, je préfère qu'il soit performant !

Revenons en à un composant que l'on veut enrichir, cela donnera alors, côté Java :
 
RequiredTextField<String> name = new RequiredTextField<String>("name"); 
name.add(new AddLabelBehavior()); 
add(name); 


et côté html :
 
<input type="text" wicket:id="name"/> 


A l'exécution, avec un fichier propriété contenant "name = Your name" on aura alors :
 
<label for="name2" >Your name : </label><input id="name2" name="name" type="text" value=""/> 


Ou, à défaut du fichier de la propriété qui va bien :
 
<label for="name2" >name : </label><input id="name2" name="name" type="text" value=""/> 


Il s'agit donc d'un "label for" tout à fait fonctionnel avec une quantité minimale d'effort.

Par contre, les behavior ne permettent pas d'ajouter d'autres composants Wicket avant ou après le composant décoré. Par exemple, si vous vouliez en profiter pour ajouter le DedicatedFeedbackPanel de l'autre jour (permettant d'avoir les messages associés à un composant à côté de lui), vous êtes bon pour réécrire ce composant dans votre onBeforeRender.

A noter que j'avais proposé sur la ML Wicket un nouveau type de composant permettant de décorer un composant précis, histoire de pouvoir ajouter des composants pré existants. Ca n'a rien donné mais je me demande si je ne vais pas insister ou tenter de le faire moi même. Time'll tell !

++
joseph