Discussion :

[felix79]

J'utilise une liste de type PropertyListView pour afficher une liste d'éléments complexes.
Sur chaque ligne j'ai un petit bouton "supprimer" : ca marche bien, la ligne concernée est bien supprimée dès qu'on clique sur le bouton.
Sur chaque ligne j'ai également un lien qui permet d'ouvrir une fenêtre modale pour voir le détail de l'objet concerné : ca marche bien également. La ou ca se corse, c'est que dans ma fenêtre modale j'ai aussi la possibilité de modifier l'objet : quand je fais "appliquer" dans ma modale, le modèle est bien mis a jour mais pas ma liste, pour voir les modification je dois cliquer sur un bouton "refresh", je n'arrive pas a le faire automatiquement.
J'ai également un bouton "ajouter" qui ouvre également une fenêtre modale afin de pouvoir ajouter un élément à la liste : là aussi je doit cliquer sur le bouton "refresh" pour voir mon nouvel élément dans la liste....
Y a t'il une subtilité pour faire en sorte que la liste se rafraichisse bien toute seule a la fermeture de ma modale ?
Je ne poste pas le code car c'est un peu long mais je le ferai si c'est utile....

[joseph_p]

chouette, une question wicket

ceci dit, sans aucun code, cela est un peu dur. Voyons ce qu'on peut faire !
- quel type de modèle a la ListView ?
- que fait le bouton refresh ?
- dans la méthode moveDownLink de ListView, on voit à la fin un appel à removeAll(), afin de forcer la ListView à rafraichir ses données au prochain affichage. Cela a t il été tenté ?

De façon générale, personnellement, je chercherai à déterminer:
- si la phase de rendu de la ListView se fait bien après la réalisation des modifications
- si le modèle de la listView prend bien en compte les modifications apportées (je pense par exemple à un LoadableDetachableModel, qui par défaut ne va pas aller à nouveau rafraichir les données au cours du même RequestCycle)

bon courage en tout cas!

++
joseph

[felix79]

Bonjour,
Merci de ta réponse !

Ma ListView utilise le modèle par défaut, c'est a dire un CompoundPropertyModel je pense....

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
PropertyListView<ExternalSystem> ls = new PropertyListView<ExternalSystem>("externalSystems", p_file.getExternalSystems())
//p_file.getExternalSystems() renvoie List<ExternalSystem>

Le bouton refresh ne fait rien a part un submit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
final SubmitLink refreshLink = new SubmitLink("refreshLink") {
    @Override
    public void onSubmit() {
        p_file.setSave(false); //ca permet de faire juste un submit du modele, sans le sauver en base
    }
};

Je ne comprend pas bien quoi faire du removeAll()....

De façon générale, personnellement, je chercherai à déterminer:
- si la phase de rendu de la ListView se fait bien après la réalisation des modifications
- si le modèle de la listView prend bien en compte les modifications apportées (je pense par exemple à un LoadableDetachableModel, qui par défaut ne va pas aller à nouveau rafraichir les données au cours du même RequestCycle)

Je ne vois pas trop comment vérifier ca non plus (je suis pas super pro en wicket en fait)....

[joseph_p]

Merci de ta réponse !

de rien !

Ma ListView utilise le modèle par défaut, c'est a dire un CompoundPropertyModel je pense....

Hum, le modèle par défaut.. La ListView est construite en lui fournissant une liste ou un modèle autour d'une liste ? J'serai curieux de voir son constructeur perso, ainsi que d'où vient la liste fournie.

A propos des modèles, je conseille vivement de passer le temps requis pour les appréhender correctement (si ce n'est pas déjà fait), notamment via http://jawher.wordpress.com/i-wrote/...les-de-wicket/

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
PropertyListView<ExternalSystem> ls = new PropertyListView<ExternalSystem>("externalSystems", p_file.getExternalSystems())
//p_file.getExternalSystems() renvoie List<ExternalSystem>

Le bouton refresh ne fait rien a part un submit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
final SubmitLink refreshLink = new SubmitLink("refreshLink") {
    @Override
    public void onSubmit() {
        p_file.setSave(false); //ca permet de faire juste un submit du modele, sans le sauver en base
    }
};

cela provoque aussi, et surtout je pense, un réaffichage complet de la page, via un aller retour client/serveur. Et vu les résultats, lorsque la page se construit elle rafraichit bien ses données... Ca sent le problème de rafraichissement de modèles.

Éventuellement, en cas de besoin très urgent, un tel ré affichage complet peut être généré via Wicket (via throw new RestartResponseException()); mais c'est pô bien, on devrait pouvoir identifier plus proprement la source du problème.

Je ne comprend pas bien quoi faire du removeAll()....

disons que si depuis la fenetre modale la list view est accessible, alors on pourrait envisager de faire : maListView.removeAll();

Je ne vois pas trop comment vérifier ca non plus

un truc simple et sympa avec wicket est que tout est côté serveur. Du coup il est possible de mettre des points d'arrêts, notamment dans la liste view.

Dans le cas précis, au vu des hypothèses que je peux faire, le plus simple est sans doute de faire ça directement dans la classe servant de modèle, sur le getObject(), afin de voir ce qui est retourné (et d'en déduire la source du mal ).

(je suis pas super pro en wicket en fait)

no prob. Ca devrait se faire assez vite

[felix79]

La ListView est construite en fournissant une liste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
ls = new PropertyListView<ExternalSystem>("externalSystems", p_file.getExternalSystems())
//p_file.getExternalSystems() renvoie List<ExternalSystem>

La listView étant dans un formulaire, c'est le modèle de ce formulaire qui est utilisé si je comprend bien, voici la création de mon formulaire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
public UpdateComponentForm(String p_name, final ComponentFile p_file, final Component p_parent) {
		super(p_name, new CompoundPropertyModel<ComponentFile>(p_file));

En toute logique c'est donc un CompoundPropertyModel qui est utilisé.
La liste utilisée par le list view provient de l'objet fourni au CompoundPropertyModel.

Ma ListView n'est pas accessible depuis ma modale...
Je pense que le modèle est bien mis a jour mais que le render de ma listView n'est pas appelé

[joseph_p]

La ListView est construite en fournissant une liste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
ls = new PropertyListView<ExternalSystem>("externalSystems", p_file.getExternalSystems())
//p_file.getExternalSystems() renvoie List<ExternalSystem>

La listView étant dans un formulaire, c'est le modèle de ce formulaire qui est utilisé si je comprend bien, voici la création de mon formulaire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
public UpdateComponentForm(String p_name, final ComponentFile p_file, final Component p_parent) {
		super(p_name, new CompoundPropertyModel<ComponentFile>(p_file));

En toute logique c'est donc un CompoundPropertyModel qui est utilisé.
La liste utilisée par le list view provient de l'objet fourni au CompoundPropertyModel.

Ma ListView n'est pas accessible depuis ma modale...
Je pense que le modèle est bien mis a jour mais que le render de ma listView n'est pas appelé

Bel enchainement de réflexion, qui achoppe je pense sur un détail:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
ls = new PropertyListView<ExternalSystem>("externalSystems", p_file.getExternalSystems())
//p_file.getExternalSystems() renvoie List<ExternalSystem>

Est ce que getExternalSystems renvoit un modèle ou directement la liste ?

Dans la seconde hypothèse, tout lien avec un éventuel modèle représenté par p_file est perdu et la liste demeure telle qu'était à la création du composant.

La javadoc de cette méthode dit justement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
/**
* Construct with a "small," unmodeled List. The object can not be detached and will reside in
* the session, but is convenient for lists of a limited size.
*

Pour lever le doute, perso je mettrai un point d'arrêt dans cette méthode de ListView:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
protected void renderItem(final ListItem<?> item)
	{
		item.render(getMarkupStream());
	}

Du coup on saurait si ce réaffichage se fait (ou pas) suite à la fermeture de la fenêtre modale et on pourrait également vérifier le contenu du modèle à ce moment donné.

NB: si besoin je pourrai faire une petite appli de démo de la fonctionnalité demandée ici: je ne suis pas expert de ModalWindows, cela me fera une bonne révision

[felix79]

Est ce que getExternalSystems renvoi un modèle ou directement la liste ?

Ca renvoie directement la liste... Donc on a probablement le problème du modèle qui ne "suit pas" dans la listView.

J'ai également mis un point d'arrêt dans le renderItem de la listView et on ne passe pas dans cette méthode à la fermeture de la modale, ce qui constitue je pense un 2eme problème....

Pour le 1er pb, j'ai supprimé la liste de mon constructeur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

new PropertyListView<ExternalSystem>("externalSystems")

Ainsi la listView va chercher directement dans le modèle du formulaire dont elle fait partie : la normalement je n'ai plus de soucis de modèle ?

Reste le 2ème pb, et la je sais pas trop quoi faire...

[joseph_p]

je viens de rentrer, et hum, , je crains de ne pas avoir trop de temps là maintenant...

quoiqu'il en soit, d'après ce que j'avais lu dans la JavaDoc, la propertyListView propose surtout un CompoundPropertyModel pour les composants ajoutés dans le onPopulateItem, et non pour et pour la liste elle même. Maintenant si la liste est dans un composant avec un compound property model, alors oui ça devrait le faire. D'ailleurs la vérification doit être assez simple: soit y a quelque chose, soit rien

sur le fond, je suis un peu gêné: perso quand je réponds aux questions j'essaie avant tout de faire avancer la personne dans sa compréhension de wicket. Maintenant, peut être que cela est trop lent, si tel est le cas ne pas hésiter à le dire, y a assurément moyen d'être plus efficace

pour la phase de rendu, le removeAll() de la listView a t il été appelé dans le callback de la Modal Windows ?

En "solution bourrine", le throw new RestartResponseException() a t il été tenté ?

in fine, je pense essayer de faire une démo plus complète demain soir, ça me permettra de mieux voir le souci je pense

++

[felix79]

Tout d'abord merci de ta disponibilité ! Pas de soucis si tu n'as pas le temps de répondre plus vite, j'ai moi même plein d'autres choses a faire et ce problème peut attendre un peu !

J'ai bien essayé le removeAll mais il n'a aucun effet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
systemWindow.setWindowClosedCallback(new ModalWindow.WindowClosedCallback() {
	public void onClose(AjaxRequestTarget p_target) {
		((MarkupContainer) get("externalSystems")).removeAll();
}
});

j'ai fait un get("externalSystems") pour récupérer ma listView car je n'ai pas de référence vers elle dans ma modale.

J'ai tenté également

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

throw new RestartResponseException(getPage());

Et ca ca marche
Mais comme tu dis c'est un peu "bourrin" : si on peut trouver une solution plus propre....

[felix79]

En fait j'ai parlé un peu vite !
le throw new RestartResponseException permet en effet de rafraichir ma liste, mais par la même occasion je perd toutes les saisies que j'ai fait dans les autres champs de mon formulaire

[joseph_p]

En fait j'ai parlé un peu vite !
le throw new RestartResponseException permet en effet de rafraichir ma liste, mais par la même occasion je perd toutes les saisies que j'ai fait dans les autres champs de mon formulaire

ça c'est un problème classique de non communication de l'état client à wicket

pour éviter cela, une méthode facile est d'utiliser un AjaxSubmitLink/SubmitLink/Button pour déclencher l'action, en prenant bien garde de signifier à wicket de ne pas faire le processus normal de validation/mise à jour des composants du formulaire, via setDefaultFormProcessing(false);

Pour le problème de façon plus générale, si je ne me trompe pas, la mise à jour de la page suite à la fermeture de la fenetre modale se fait via Ajax, correct ? Si oui, alors il faudrait penser à inclure la ListView parmi les composants à mettre à jour, est ce fait ?
Si ce n'est pas le cas, voici un bel exemple de fenêtre modale: Gérer facilement les fenêtres modales avec Wicket. La dernière partie aborde justement ce dont on discute

[felix79]

Ca progresse mais c'est pas encore tout a fait ca. Je résume mon cheminement
Je me suis déjà inspiré du lien dont tu parles pour d'autres modales et ca fonctionne en effet très bien quand on a un champs dans une modale et un champs du même nom dans le formulaire principal que l'on va mettre a jour.
Mon exemple est un peu différent et je me retrouve avec un problème de références croisées :
Dans le populateItem de ma listView je défini un lien qui permet d'ouvrir une modale avec les données d'un des éléments de ma liste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
protected void populateItem(ListItem<ExternalSystem> p_item) {
	final ExternalSystem system = p_item.getModelObject();
	AjaxLink<String> systemLink = new AjaxLink<String>("systemLink") {
		@Override
		public void onClick(AjaxRequestTarget p_target) {
			p_target.appendJavascript("Wicket.Window.unloadConfirmation = false;");
			systemPanel.updateDisplay(system);
			systemWindow.show(p_target);
		}
	};
	systemLink.add(new Label("systemName"));
	p_item.add(systemLink);

La modale (systemWindow) et le panel qui va avec (systemPanel) doivent donc être initialisés avant ma listView.

Maintenant si je dois inclure la listView parmis les composants à mettre a jour comme indiqué, ca donne un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
final ExternalSystemPanel systemPanel = new ExternalSystemPanel(systemWindow.getContentId(), p_parent) {
	@Override
	public void onSave(AjaxRequestTarget p_target, Form<?> p_form) {
		p_target.addComponent(listView);

Ce qui implique que listView soit initialisé avant le systemPanel...
Qu'a cela ne tienne, je vais passer une référence sur ma listView lors de l'ouverture de la modale, ce qui me permettra de la retrouver au moment de la fermeture.
Je peux donc maintenant faire p_target.addComponent(listView)
La je rencontre un nouveau probleme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

This component is a repeater and cannot be repainted via ajax directly. Instead add its parent or another markup container higher in the hierarchy.

pas de soucis, j'essai de passer le parent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

p_target.addComponent(listView.getParent())

Et la miracle ca a l'air de fonctionner ! Ma listView est bien mise a jour a la fermeture de la modale...
Sauf qu'il y a un petit pb : tous les autres champs du formulaire que j'ai pu remplir avant sont vidés (j'ai essaye le ajaxSubmitLink avec setDefaultFormProcessing(false) : c'est pareil)...
Je suppose que ca vient du fait que je passe le parent, et donc tous les élements qui sont au meme niveau que la listView sont reinitialisés....
L'idée serait peut être de mettre la listView dans un MarkupContainer qui ne contiendrait qu'elle et qu'on pourrait passer au "addComponent"... Quel type de MarkupContainer serait éligible a ton avis ?
Merci encore pour ton aide : on est tout près du résultat !

[felix79]

Cette fois ca y est ca marche !!!!
J'ai juste inclus ma ListView dans un simple WebMarkupContainer et ca roule....
Merci de ton aide Joseph

[joseph_p]

Cette fois ca y est ca marche !!!!

excellent, bravo !

A propos, j'avais zappé un peu ce bout de code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

((MarkupContainer) get("externalSystems"))

=> perso je ne cherche jamais à atteindre des composants par leur id. Je ne sais même pas si/comment ça marche (faut il par exemple donner le chemin complet?).

A ma connaissance, c'est surtout réservé à un usage interne à wicket (qui utilise les chemins des composants dans les liens par exemple).

Si j'ai besoin d'un composant dans un différent contexte, je fais alors en sorte de mettre la main sur sa référence (ou encore mieux je découple via des méthodes/objects idoines).

Merci de ton aide Joseph

c'est un plaisir