Scores Wicket et Complex Ajax

Question

Lorsqu'un écran possède plusieurs contrôles Ajax interagissant et que vous voulez contrôler la visibilité des composants pour réagir à ces contrôles (afin que vous n'affichez que ce qui est logique dans une situation donnée), appelez manuellement target.addComponent() sur tout vous voulez mettre à jour devient encombrant et n'est pas très maintenable.

Finalement, le web de onClick et onUpdate rappels peuvent atteindre un point où l'ajout d'un nouveau composant à l'écran devient beaucoup plus difficile que ce qu'il est censé être. Quelles sont les stratégies couramment utilisées (ou même les bibliothèques si une telle chose existe) pour éviter cette accumulation de complexité?

Mise à jour: Merci pour vos réponses, je les ai toutes trouvées très utiles, mais je ne peux en accepter qu'une. Pardon.

Answer 1

Eh bien, de combien de composants parlons-nous ici? Dix? Vingt? Des centaines?

Jusqu'à 20 ou environ, vous pouvez avoir un contrôleur d'état qui contrôle quels composants doivent être affichés. Ce contrôleur définit le champ visible d'un modèle de composants et vous ajoutez toujours tous les composants à vos demandes qui sont traitées par le contrôleur. Les événements ajax des composants que vous redirigez simplement vers la méthode du handle du contrôleur.

Pour un très grand nombre de composants qui ont une charge utile trop lourde pour une bonne performance, vous pouvez utiliser des bibliothèques javascript comme jQuery pour faire le show et cacher des choses par le client.

Answer 2

Vous pouvez ajouter des composants structurels tels que WebMarkupContainer s, lorsque vous ajoutez cela à l'AjaxTarget, tout ce qu'il contient sera également mis à jour. Cela vous permet de mettre à jour des groupes de composants sur une seule ligne.

Answer 3

Dans Wicket 1.5, il existe un bus d'événements. Chaque composant a la méthode onEvent (Object payload). Avec component.send(), vous pouvez diffuser des événements et chaque composant peut vérifier la charge utile (par exemple, l'objet UserJoinedEvent) et décider s'il souhaite participer à la réponse Ajax en cours. Voir http://www.wicket-library.com/wicket-examples/events/ pour une démo simple.

Answer 4

J'utilise actuellement une sorte de modèle Observer modifié pour simuler un bus d'événements dans Wicket 1.4. Mes pages agissent comme observateur observable car mes composants ne se connaissent pas et sont réutilisés dans différentes combinaisons sur plusieurs pages. Chaque fois qu'un composant reçoit un événement Ajax qui pourrait également affecter d'autres composants, il appelle une méthode sur sa page avec un objet-événement et la cible ajax. La page appelle une méthode similaire sur tous les composants qui se sont enregistrés pour ce type d'événement et chaque composant peut décider, sur la base de l'objet-événement fourni si et comment il doit réagir et peut s'attacher à la cible.

La même chose peut être archivée en utilisant le visiteur de guichet. Je ne sais pas lequel est le meilleur, mais je pense que c'est principalement une question de goût.

Answer 5

Lorsque je crée des composants pour une page que je tendance à les ajouter aux tableaux composants:

Component[] pageComponents = { 
        new TextField<String>("Field1"), 
        new TextField<String>("Field2"), 
        new TextField<String>("Field3") 
} 

Au Wicket 1.5 les fonctions add prennent des paramètres de tableau [1].Par conséquent, les éléments peuvent être ajoutés à la page ou de la cible comme ceci:

add(pageComponents); 
target.add(pageComponents); 

Les composants peuvent ensuite être regroupés en fonction de laquelle vous souhaitez rafraîchir ensemble.

[1] http://www.jarvana.com/jarvana/view/org/apache/wicket/wicket/1.5-M3/wicket-1.5-M3-javadoc.jar!/org/apache/wicket/ajax/AjaxRequestTarget.html