[Ben]

Juhu,
ich baue mir gerade eine kleine Testanwendung, an der ich mich mal etwas in Sachen MVC & Co. austesten möchte.

Nun gut.
Ich habe hier jetzt mal zwei Bekannte von mir gefragt, wie ich die Listener in den Menüs verteile.
Der eine sagt, dass er pro Hauptmenü in der JMenuBar einen Listener vergibt und dann mit if/elseif/else bzw. switch arbeitet und der andere sagt, dass er jedem JMenuItem einen Listener anhängt.

Was ist denn da zu empfehlen? Von "richtig" und "falsch" möchte ich mal nicht reden, weil ich nicht weiß, ob man einen anderen Stil als "falsch" bezeichnen kann

Danke für Eure Antworten.
Grüße Ben.

[pago]

Richtig: Verwende eine "Action" für die Menüs.

ActionListener ist als Zusatz gedacht, bzw. war der Vorgänger der Action-Klasse.
Guck mal im Java-Tutorial nach, da ist ein nettes Kapitel dazu.

Switch / If-else dafür zu benutzen mag ich gar nicht. Du musst dafür nämlich immer irgendwo eine Referenz auf alle menüelemente und Buttons haben. Finde ich ziehmlich zwecklos.

[`B]

ich finde es hat beides vor und nachteile.

Ich bin ja einer von diesen Bekannten und arbeite mit switch / if / else - für mich hat sich das einfach am praktikabelsten erwiesen damit zu arbeiten. Diese basieren natürlich auf Listenern welche die entsprechende Funktion zum auswerten aufrufen.

Also im direkten Vergleich aus der View ein Ausschnitt aus der Methode welche die JMenuItems erzeugt:

menuItem.addActionListener(
new ActionListener() {
		public final void actionPerformed(final ActionEvent e) {
			switchEvent(Konstanten.MENUE_EINTRAG_EREIGNIS[ a ][ b ]); 
		}
	     }
 );

Sieht nun ein wenig wirsch aus, aber ich habe da so ca. 40 MenuItems und mir eine Iterative Lösung ausgedacht wie ich die erzeuge und dennoch alle direkt ansprechbar halte.

Die Methode switchEvent(int pEvent) leitet das in der View erzeugte Event dann direkt weiter an zwei HauptController bei mir, also differenziert das noch kurz mit einmal If / Else nach zwei Feldern. Entweder wird ein DialogFenster benötigt und geöffnet oder einfach ein Ereignis im Hintergrund ausgeführt mit anschließender Bestätigung, da Dialoge variabel anpassbar bleiben sollen ohne tief im Source zu wühlen habe ich denen eine eigene Controllerklasse zugewiesen und somit da eine klarer/sinnvollere Struktur eingebracht.

Die beiden Controller selbst greifen dann auf entsprechende Klassen zu und stellen ausschließlich Anfragen. Sollten keine Programmrelevanten Daten zurückkommen müssen, so bekommt der Controller eine boolean zurück um zumindest einen Fehler mitteilen zu können. switchEvent selbst ist allerdings ein Auftrag (void).

Für bessere Lösungen bin ich jederzeit offen. Der Übersicht halber müsste man mal ein UML Diagram posten können, leider kenne ich kein Plugin für Eclipse welches vorhandenen Source analysiert und ein entsprechendes Bitmap o.ä. dann erzeugt.

Grüße

Florian

[Ben]

@TheDragonMaster:
Ich habe jetzt das hier mal überflogen:
--> http://java.sun.com/docs/books/tutor...sc/action.html

Jetzt ist aber ja Action ein Interface.
Schreibe ich jetzt für jedes MenuItem eine eigene Klasse?


@`B:
Danke für den Beitrag. Grob verstehe ich das glaube ich auch .. allerdings geht mir persönlich das jetzt etwas zu schnell ...


EDIT:
Nachtrag.
Also das hier:

PHP-Code:

        menuItem.addActionListener(
                new ActionListener() {
                        public final void actionPerformed(final ActionEvent event) {
                            System.out.println("hallo");
                        }
                }
        ); 


finde ich irgendwie intuitiver.

Ich frage mich jetzt allerdings gerade .. warum vor dem ActionEvent ein "final" steht ... könnte mir eventuell in einem Nebensatz beantwortet werden.

Danke

[pago]

@Ben: Es gibt eine Klasse "AbstractAction".
Die übernimmt die meisten Sachen.
Als Ergebnis kannst du die fast so nutzen, wie einen ActionListener. Der Vorteil von Actions zeigt sich aber spätestens, wenn es zu Sachen wie i18n kommt.

Das "final" hat keine wirkliche Bedeutung. Kann man da hinsetzen (damit man nicht irgendwo auf die Idee kommt, sowas wie "event = new..." zu schreiben), muss man aber nicht.

[Ben]

Zitat von TheDragonMaster

@Ben: Es gibt eine Klasse "AbstractAction".
Die übernimmt die meisten Sachen.
Als Ergebnis kannst du die fast so nutzen, wie einen ActionListener.

Habe ich ehrlich gesagt nicht so ganz verstanden.

Die Klasse war mir schon bekannt. Daran hapert es nicht. Aber ich habe mit ActionListener immer bzw. häufig als anonyme Klasse gearbeitet, also direkt implementiert.

Wie gehe ich denn vor, wenn ich jetzt so eine Action mit Infos füllen will.
Das Beispiel aus dem Java-Tutorial ist mir irgendwie so speziell.

Da wird ja ein Array gefüllt und dann werden die Actions dem Menu hinzugefügt .. mach ich das jetzt auch so, oder wie?

Das wäre ja dann wieder diese Frage hier:

Zitat von Ben

Schreibe ich jetzt für jedes MenuItem eine eigene Klasse?

Danke, Ben

[pago]

// Irgendwo dort, wo die GUI gebastelt wird
JMenuBar mb = new JMenuBar();
JMenu m = new JMenu("Datei");
m.add(new OpenFileAction());


// OpenFileAction.java
public class OpenFileAction extends AbstractAction {
    public OpenFileAction() {
        super("Öffnen");
        putValue(Action.ACCELERATOR_KEY, KeyStroke.parseKeyStroke("control O"));
    }
    
    public void actionPerformed(ActionEvent e) {
        // Action-Code
    }
}

Da du eh MVC verwenden willst, solltest du auf anonyme Klassen verzichten können.

[Ben]

Ok. Gut.
Das sieht mir gut strukturiert aus. Das werde ich dann mal so weiterverfolgen

Danke erstmal. Eventuell komme ich aber nochmal hierauf zurück.

Grüße Ben

[nove]

blässt man nicht auf diese Art und Weise die Anwendung auf? z.B. wenn es ein sehr Umfangreiches Menü wird.

[pago]

Wenn man es "richtig" macht, dann nicht.
Die Aktionen, die per Menü verfügbar sind, sind ja meistens auch noch irgendwo anders als Buttons verfügbar. So lässt sich eine Action wiederverwerten (ich packe die z.B. gern in eine Map).

Wenn man dann noch das "Command"-Pattern anstelle einer einfachen Action verwendet, kann man die Action eigentlich überall verwenden, und sie wird zum tatsächlichem Controller, der sie seien sollte.

Für die neue Version meines "SimpleEdit" bin ich aber einen anderen weg gegangen, und habe den Action-Code dank Beanshell in eine XML-Datei "abgeschoben". Für die relativ kleinen Operationen, die dort durchgeführt werden, lohnte es sich nicht, zig neue Klassen anzulegen (wobei ich momentan mit dem Gedanken spiele, dass wieder zu ändern...).
Bei mir wird dann anhand der ID der Action, die zusammen mit dem Code in der XML-Datei steht, und eines ResourceBundles die Konfiguration der Action übernommen (Titel, Icon, Shortcut).

"a final variable means you can't change its value" aus HeadFirst Java, Seite 283.