Lier un InterfaceGrph avec un chargement d'un fichier

Bonjour,

Je charge un fichier (on s'en fou de la nature du fichier) avec des exceptions dedans.

public class GedcomFile extends Exception
{...
}

Ma fonction qui traite le fichier:
public void runConversion() throws ErreurConversion
{...
}

J'ai une variable qui indique a quel etape se trouve la conversion du fichier. Cette variable se trouve toujours dans la class GedcomFile.

Je voudrai une interface Graphique par dessus qui indique l'étape encours.

Mais voila, en QT on pouvait créer des événements, et donc dans ce cas de figure ma classGedcomfile aurait pu envoyer un signal à chaque changement d'tape à ma class correspondant à mon interface graphique. Ainsi mon interface pourrait etre au courant de l'étape en cours.

Mais en JAVA je sais pas comment faire...
J'ai pensé à un implements ActionListener dans mon interface graph. et la méthode actionPerformed(ActionEvent evt) dedans qui serait appelé en continu. Selon l'étape en cours aurait avancer la barre de progression par exemple. Mais voila mes idées s'arrete là lol.

Citation:

---

Envoyé par dr23fr

Bonjour,

Je charge un fichier (on s'en fou de la nature du fichier) avec des exceptions dedans.

public class GedcomFile extends Exception
{...
}

Ma fonction qui traite le fichier:
public void runConversion() throws ErreurConversion
{...
}

J'ai une variable qui indique a quel etape se trouve la conversion du fichier. Cette variable se trouve toujours dans la class GedcomFile.

Je voudrai une interface Graphique par dessus qui indique l'étape encours.

Mais voila, en QT on pouvait créer des événements, et donc dans ce cas de figure ma classGedcomfile aurait pu envoyer un signal à chaque changement d'tape à ma class correspondant à mon interface graphique. Ainsi mon interface pourrait etre au courant de l'étape en cours.

Mais en JAVA je sais pas comment faire...
J'ai pensé à un implements ActionListener dans mon interface graph. et la méthode actionPerformed(ActionEvent evt) dedans qui serait appelé en continu. Selon l'étape en cours aurait avancer la barre de progression par exemple. Mais voila mes idées s'arrete là lol.

---

Il faut utiliser le Design Pattern "commande" (je crois que c le nom).
C'est exactement le même fonctionnement de ActionListener...

En fait, tu te fais une interface ChargementListener par exemple, avec une méthode etatChangé(Etat etat);
Et dans ton interface graphique, tu implémentes l'interface ChargementListener, et tu définis ce que tu dois faire qd l'état a changé...
Du côté du "modèle", il suffit que tu appelles la méthode etatChangé(nouvelEtat), ça "envoie" un signal à l'interface graphique si on peut dire :)

J'ai rien compris ! :(
Design pattern "commande" sous google ca donne rien. je sais pas ce que c'est et encore moins ce que ca veut dire.

n fait, tu te fais une interface ChargementListener par exemple, avec une méthode etatChangé(Etat etat);
Et dans ton interface graphique, tu implémentes l'interface ChargementListener, et tu définis ce que tu dois faire qd l'état a changé...


Je comprends que je créé une interface:
interface ChargementListener
{
etatchange(int nouvellevaleur);
}

class GUI implements ChargementListener
{
etatchange(int nouvellevaleur)
{
//avancer progressbar
}
}

Du côté du "modèle", il suffit que tu appelles la méthode etatChangé(nouvelEtat), ça "envoie" un signal à l'interface graphique si on peut dire

Le vide !!!!!! pas compris.
MErci de m"aider en tout cas

Citation:

---

Envoyé par dr23fr

Du côté du "modèle", il suffit que tu appelles la méthode etatChangé(nouvelEtat), ça "envoie" un signal à l'interface graphique si on peut dire

Le vide !!!!!! pas compris.
MErci de m"aider en tout cas

---

Bah, en gros tu dois avoir un attribut listeners de type Collection<ChargementListener>, et des méthodes addChargementListener() / removeChargementListener().
Tu peux te faire aussi une méthode privée / protected:

Code:

---

1 2 3 4

protected void fireChange(int etat) { for(ChargementListener listener : listeners) listener.etatChange(etat); }

---

Ensuite, dès que tu passes une étape de chargement (à l'endroit où tu veux envoyer un signal), tu fais simplement fireChange(nouvelEtat).

nan mais là c'est pire qu'avant.:cry: :aie:

J'ai d'un coté ma classe GUI et de l'autre une class File avec la fonction qui traite le fichier dans File.

Dans ce que tu m'as di, je vois pas un seul instant le lien entre GUI et File.

Je vois pas enquoi faire fireChange(nouvelEtat). dans File va dire à ma GUI de changer d'étape. Car c'est la class File qui décide du changement de l'étape.

Citation:

---

Design pattern "commande" sous google ca donne rien

---

essaye "pattern command java", et tu auras plein d'exemples... :google: est ton ami quand même, même si il faut le forcer des fois... :mouarf:

Citation:

---

Envoyé par dr23fr

nan mais là c'est pire qu'avant.:cry: :aie:

J'ai d'un coté ma classe GUI et de l'autre une class File avec la fonction qui traite le fichier dans File.

Dans ce que tu m'as di, je vois pas un seul instant le lien entre GUI et File.

Je vois pas enquoi faire fireChange(nouvelEtat). dans File va dire à ma GUI de changer d'étape. Car c'est la class File qui décide du changement de l'étape.

---

Ta classe file, elle a en attribut une liste de ChargementListener.
Lorsque tu fais fireChange(nouvelEtat), ça appelle la methode etatChange() de tous les listeners.

Ton interface implémente l'interface ChargementListener, donc tu peux faire à partir de ton interface monFile.addChargementListener(this);

Et voilà le lien :)

Pour créer un système d’événement, tu crées tout d’abord une interface qui représente ce que les écouteurs (classe qui recevront l’événement) doivent obligatoirement implémenter :

Code:

---

1 2 3 4

public interface ConversionStateListener{ public void stateChange(ConversionState state) ; }

---

Remarque : ConversionState est une classe qui permet de donner l’état … fais une énumération, même un int pour donner l’état ou autre cela importe peu …

Puis tu ajoutes une propriété (n’importe quelle collection selon tes besoins, ici un simple Vector pour la simplicité) Vector<ConversionStateListener> stateListeners = new Vector<ConversionStateListener>() dans ta classe de conversion. Ensuite dans la même classe tu ajoutes 2 méthodes qui te serviront à ajouter/supprimer tes listeners :

Code:

---

1 2 3 4 5 6 7

public void addStateListener(ConversionStateListener l){ stateListeners.add(l) ; }   public void removeStateListener(ConversionStateListener l){ stateListeners.remove(l) ; }

---

Toujours dans ta classe de conversion crée une méthode :

Code:

---

1 2 3 4 5

private void raiseChangeStateEvent(ConversionState state){ for (Iterator it = stateListeners.iterator(); it.hasNext(); ) { ((ConversionStateListener)it.next()).stateChange(state) ; } }

---

Celle-ci va servir à appeler la méthode de tous les objets qui écoute cet évènement.

Ensuite quand tu lances ta conversion tu ajoutes ton objet du GUI en tant que listener en faisant :

Code:

---

1 2 3

… addStateListener(monObjetGUIQuiImplemente_StateChangeListener) …

---

de cette façon quand tu changes l’état, dans ta méthode de conversion, tu as juste à faire :

Code:

---

1 2 3

… this.raiseChangeStateEvent(new ConversionState(….)) ; …

---

Ta classe de GUI doit implémenter ton interface ConversionStateListener donc tu lui rajoutes implements ConversionStateListener. Par conséquent, tu implémentes la méthode stateChange afin de gérer ta progressbar ou autre de ton GUI …

Voilà j'espère avoir été claire et surtout qu'il ne manque rien ;-)

A noter que l’utilisation du pattern command est aussi une solution …

Citation:

---

Envoyé par julien_chable

A noter que l’utilisation du pattern command est aussi une solution …

---

C'est exactement ce que tu as décrit le pattern command, non?

Merci ca fonctionne nikel et je vais pouvoir appliquer cette facon de faire à plein de truc. trop content.
merci

Non non cela n'a rien à voir avec le pattern Command (imbracation de classes comme un brochette .. par exemple les Stream de l'API java.io utilise le pattern Command) ..
Je crois que ce pattern s'appelle le Listener mais je ne garantie pas ce

++

Citation:

---

Envoyé par julien_chable

Non non cela n'a rien à voir avec le pattern Command (imbracation de classes comme un brochette .. par exemple les Stream de l'API java.io utilise le pattern Command) ..
Je crois que ce pattern s'appelle le Listener mais je ne garantie pas ce

++

---

OK

J'étais persuadé qu'il s'appelait commande...
C'est vrai que Listener est approprié...
A ce propos, y'a-t-il une différence entre l'appellation Listener et Observer (écouteur/observateur)?

Et Command, tu peux expliquer un peu plus stp, je n'ai pas compris ce que c'est :)