
Envoyé par
ZedroS
salut
je pense que ton souci est plus général que juste les onglets, et concerne en fait de façon plus générale la gestion de ce qui s'affiche.
Avec wicket, les éléments html déclarés via des wicket:id seront gérés côté serveur, par ton code. Ces éléments html seront associés à des composants qui eux mêmes sont associés à des données.
Ce qui est affiché est défini lors de la construction de la page puis réévalué lors de chaque "requestcycle", autrement dit lors de chaque action utilisateur entrainant un traitement côté serveur.
Le cas de l'ajax est un peu différent : au lieu de systématiquement tout recharger, on cherche à gagner en perf en ne réaffichant que le strict nécessaire, d'où la notion de "target" qui permet de définir la "cible" de ce qui sera réaffiché, via target.addComponent(). Dans ce cas précis, seuls les éléments faisant partis de la cible seront réévalués afin de déterminer leur nouvel affichage. Petite restriction à noter : on peut pas ajouter la page à la cible. Dur donc à priori de tout réafficher... sauf si on fait setResponsePage(getPage()) dans la méthode Ajax, qui redirige vers la présente page, qui voit alors tous ces éléments ré évalués et ré affichés.
J'ai donc présenté rapidement comment les composants wicket étaient évalués en vue de leur affichage. Reste à définir deux choses : leurs présences (ou non) et leur données.
Pour leur présence, autrement dit leur visibilité, la meilleure façon de procéder est de surcharger la méthode isVisible au sein des composants dont on veut maitriser la visibilité. Cette méthode est systématiquement appelée à chaque affichage et pilote bien évidemment la présence du composant.
Pour les données, leur ré actualisation dépend en fait du type de modèle associés. Un model "par défaut" (comme pour les label par exemple), voit sa valeur déterminée uniquement lors de la construction du composant. Pour que les données derrière le modèle soient ré évaluées, il faut des PropertyModel, dont les données sont derrière le modèle sont interrogées à chaque fois, ou des LoadableDetachableModel, dont les données derrières le modèle sont ré interrogées une fois en début de chaque RequestCycle.
Ainsi, une méthode isVisible surchargée mais interrogeant des données non rafraichies ne verra pas son état changer.
Enfin, on peut noter la présence de composants pouvant contenir d'autres composants, par exemple les panel ou les webmarkupcontainer. Ces éléments permettent de piloter de façon plus globale la visibilité ou non d'un ensemble de composants. Ils évitent donc d'avoir à surcharger 50 isVisible dans autant de composants, vu qu'on ne le fait que pour le composant parent.
Ces éléments t'aident ils ? Y a t il des parties qui sont floues ? Si oui, n'hésite pas à poser plus de questions.
Concernant ton problème, peux tu m'indiquer en termes "wicket" ce que tu veux faire ? Voir me montrer ton code ? Où et comment comptes tu piloter la visibilité ou le contenu affiché ?
Partager