Grouper les événements.

Bonjour à tous,

Pour une application je possède des models qui envoie des événements à chaque fois qu'une propriété change. Par exemple, j'ai des fonction setX(), setY(), setWidth(), etc.

J'ai également des fonctions qui écoutent ces événements et qui peuvent parfois être assez lourd et prendre beaucoup de ressources.

Il est possible de modifier, par un panneau, plusieurs propriétés en même temps. Cela fait que plusieurs événements sont envoyés et mes fonctions sont exécutés plusieurs fois alors qu'il suffirait d’exécuter la fonction une seul fois, quand toutes les propriétés ont étés changées.

Je voudrais donc savoir s'il était possible de grouper les événements afin d'optimiser mon code.

Qu'en pensez vous?

Merci d'avance.

Là, comme ça, je dirais : faire en sorte que chacune d'entre elles délègue à quelque chose comme changeDimensions(), qui envoie un seul événement, récapitulant tout ce qui a changé.
(Au fait, ça c'est plutôt dans la section swing & al.)

Je ne sais pas si on c'est bien compris mais c'est mon model qui envoie les événements et pas swing. Voici un exemple de fonctions (je n'ai pas le code sous la main) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public void setX(x) { if ( this.x != x ) { this.x = x; sendEvent(); } }   public void setY(y) { if ( this.y != y ) { this.y = y; sendEvent(); } }

---

Et voici le code qui s'appelle quand je clique sur le bouton "modifier" de mon panneau :

Code:

---

1 2 3 4 5

public void function applyModification() { object.setX(newX); object.setY(newY); }

---

On peut donc voir que quand on exécute la fonction applyModification, la fonction "sendEvent" est appelé deux fois et donc toutes les fonctions écoutant ces événements aussi. Encore une fois il s'agit d'exemples car je n'ai pas le code disponible maintenant. Dans mon cas, il suffirait que ça soit uniquement le dernier événement qui soit appelée. Par contre je ne peux pas appelé un événement uniquement dans la fonction setY car cela serait gênant au niveau de l'architecture de l'application.

Qu'en pensez vous?

D'après ce que j'ai compris, vous expliquez que plusieurs évennements (dont le nombre n'est pas prédictible) peuvent survenir (y a-t-il un ordre respecté ?) entraînant pour cetains d'entre eux l'exécution de la même méthode, et vous voudriez économiser vos ressources en évitant ces redondances.
Je penses que cela ne peut être possible que si le 'train' d'évennement concerne une même action unique. On pourrait alors s'inspirer d'un getValueIsAdjusted qui serait mis à faux par le dernier sendMessage pour permettre au thread de traitement de démarrer l'exécution du train d'évennement en prenant soin de supprimer les redondances juste avant exécution. Mais si chaque evennement concerne une action différente et doit être traité immédiatement, je ne vois pas comment cela pourrait être possible ? Il faudra de toute façon passer par un buffer ?!....8O

Les fonctions écoutant setX et setY sont les mêmes.

Ta solution semble intéressante. As tu un exemple de code existant?

Par contre, il n'y a pas vraiment d'ordre à respecter et je pense qu'il ne faudrait pas en avoir. Ça complique un peu les choses parce-que je ne peux pas dire à ma dernière fonction d'en appeler une autre qui traiterai les événements. Je ne voudrais pas non plus appeler cette fonction explicitement car je pense cela gêne l'architecture.

Peut être que je pourrais passer par un timer de 100ms (par exemple) qui se réinitialiserai à chaque fois que l'on ajoute un événement et qui ferai en sorte que, une fois que le temps est dépassé, ça exécuterai tout les événements.

Le traitement serai le suivant :

• J'ajoute l'événement appelé par setX à la pile
• J'initialise le timer à 100ms
• J'ajoute l'événement appelé par setY à la pile
• Je remet le timer à 100ms
• Les 100ms se passent et j’exécute les événements en supprimant les redondances

Qu'en pensez vous?

Solution 1)
Pourquoi ne pas "déplacer" la gestion des événements au code appelant les beans ?

Solution 2)
Les événements sont bufférisés comme indiqué. Seulement je mettrais en place un EventNotifier. Comme ça les abonnements ne changent pas. C'est uniquement le sendEvent(), et ajouter un setEventNotifier aux beans.
Attention de gérer le fait que si un événement arrive toujours avant la seuil (ici 100ms), les événéments sont indéfiniment stockés et jamais notifiés.

Solution 3)
Un mix entre les deux avec un EventManager.
La couche appelante ouvre une "transaction" à partir de laquelle tous les événements vont être bufferisé. Après le traitement, la "transaction" est fermée (released) et les événements bufférisés sont transmis aux observateurs en un seul flux.
Attention de bien prévoir l'ouverture/fermeture de flux (le pattern Command est idéal pour cela) et de penser aux éventuelles "encapsulation" de transaction.