✔ Actions verteilen wie in einer mailinglist

[melmager]

Also ich habe folgendes Problem zu lösen :
Ich habe mehrere Textfelder die ein Event auslösen - soweit so normal - nur in der Classe die davon informiert wird kann es zu Ereignissen kommen aus einer andren Quelle die es nötig machen den Text im Textfeld zu ändern.
Ich muss also auch Actions erzeugen auf die dann die Eingabefelder hören um sie zu actualisieren.
Sprich es gibt Quellen die ein Action auslösen aber die auch auf welche hören sollen - wie bei einer mailinglist

Jetzt die frage wie implementiert man sowas am geschicktesten ?

mein derzeitiger Ansatz ist der:
erstmal eine Eventclasse

class TextMessageEvent extends EventObject {
 enum TextType {
  LYRIC,WORK,CREATOR,SONGNAME;
 }

 String message;
 TextType typ;

 public TextMessageEvent(Object source, TextType id, String text) {
   super(source);
   this.typ = id;
   this.message = text;
 }
}

dann braucht man ja noch ein Interface für die geneigten zuhörer

public interface TextMessageListener extends EventListener {
 public newMessage(TextMessageEvent msg);
}

Jetz kommt die Mailinglist classe - jeder kann was einstellen und jeder wird informiert der auf der liste ist

und da stocke ich grade

class TextMessageOffice implements ActionListener {
 // ActionListener Interface
 public void actionPerformed( ActionEvent e ) {
 }
}

klar muss die classe auf Actions hören um von den Eingabefeldern informiert zu werden

und ich müsste nu den eigenen Event erzeugen - auch klar - aber wie verteile ich den am besten ?
nutzen von
Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent()
oder gleich selber in der OfficeClass die Listener aufrufen ?
die zweite Version würde anbeiten das ich in der Officeclasse schon vorsortieren könnte wer unbedingt informiert gehört.
wenn ich über dieQueue gehe müsste der listener seine nachrichten rausfiltern - auch kein Thema

oder ganz von swing weg und für eigene nachrichten auf observer aufsetzen ?

 

[melmager]

Ich glaube die beans binding changelistener ist meine Lösung
nur wie implementiert man sowas ?
da habe ich noch dicken nebel :-(

nachtrag: Beans und Binding ist tatsächlich ein Lösungsweg.

ein Swing Element wie jText (Texteingabefeld) erfüllt auch die Bedingungen für ein Bean.
Ein Bean hat unter andrem eine gebundene Eigenschaft (bei jText ist das text) die mit getText() und setText()
erreicht werden können. Wenn die Eigenschaft sich ändert wird ein PropertyChange ausgelöst der dann alle PropertyChangeListener informiert. Durch die Namensgebung die durch das Beanprinzip vorgesehen ist kann eine Eigenschaft also von einem Bean zum andren Bean übermittelt werden - und das kann in beide richtungen gehen.
Diese Verbindung wird durch die Classe Binding realisiert.
bean - binding - bean

also Textfeld BPM (eingabe Tempo) ist ein bean[text]
- feststellen wer alles informiert gehört das sind in meinem Fall 3 Klassen (die dann auch das Beanprinzip erfüllen müssen)

also braucht es 3 Bindings
bpm[textbean] - binding - metronom[bpmbean]
bpm[textbean] - binding - storage[bpmbean]
bpm[textbean] - binding - midi[bpmbean]

wenn ich nun im bpm Feld eine änderung eingebe werden also die classen informiert - soweit war ich ja schon mal , aber dadurch das es auch andersrum geht bekommt das Textfeld auch mit wenn sich im Midi die bpm einstellung ändert und das informiert dann wider die andren Classen . Dadurch das nur dann ein Event ausgelöst wird wenn eine Eigenschaft sich ändert kann es auch zu kein loop/rückkopplungseffect kommen.

bindings siehe: http://doc.formdev.com/beansbinding/

die Bindings können dann noch zu einer BindingGroup zusammengefasst werden - kann man sich wie eine Liste für Bindings vorstellen.

- sprich es herrscht bei mir nur noch leichter Nebel weil ich das Prinzip mittlerweile verstehe - irgendwann mache ich mal ein Tutorial dazu