Wenn ich eine Swing-Anwendung (oder eine beliebige UI-Anwendung) erstelle, habe ich normalerweise verschiedene Aktionen, die auf Menüelementen und Schaltflächen angezeigt werden. Ich erstelle normalerweise eine Aktionsregistrierung und speichere die Aktionen dort. Wenn bestimmte Dinge eintreten, deaktiviere / aktiviere ich Aktionen in der Registrierung basierend auf dem Status der Anwendung. Ich würde mich selbst nicht als eifrigen Swing-Entwickler bezeichnen, obwohl ich mich gut genug auskenne, aber ist das ein ziemlich typisches Muster für die Verwaltung von Aktionen? Oder gibt es eine Standardmethode dafür?
Danke,
Jeff
Jeff, Ihr Ansatz scheint ein guter Ansatz zu sein. Ich mache dasselbe. Ich rufe die Registrierung ActionHandler und es sieht so aus:
%Vor%Jetzt zum Deaktivieren, sagen ZoomAction, verwende ich
%Vor% Aus meiner Erfahrung heraus besteht der ' most ' Standard für die Handhabung von Aktionen auf einer Swing-GUI darin, ActionListener s zu erstellen und sie direkt für die Komponenten, mit denen sie arbeiten, mit ActionEvent s zu behandeln sind registriert. Es ist ein einfaches Design und folgt Konvention mit anderen Arten von GUI-Ereignissen im Swing-Framework ( MouseListener / MouseEvent , TableModelListener / TableModelEvent , usw.).
Das Action -Framework, das Sie beschreiben, ist ein mächtiges Werkzeug, um die gemeinsame Nutzung von Aktionen zwischen vielen Eingabemethoden zu ermöglichen (dh eine Symbolleistenschaltfläche und einen Menüeintrag führen die gleiche Aktion aus und teilen daher dieselbe Object für die Handhabung der Ereignisse, die von beiden ausgelöst werden, usw.). Diese Abstraktion ist ziemlich cool, aber Sun warnt, dass es etwas schwerer ist als die einfachen Beobachter. Aus der Action JavaDoc:
Beachten Sie, dass Action-Implementierungen im Hinblick auf den Speicher teurer sind als ein typischer ActionListener, der nicht die Vorteile einer zentralisierten Kontrolle der Funktionalität und der Übertragung von Eigenschaftsänderungen bietet. Aus diesem Grund sollten Sie darauf achten, nur Aktionen zu verwenden, wo ihre Vorteile erwünscht sind, und an anderer Stelle einfache ActionListener verwenden.
Ich gehe normalerweise folgendermaßen vor:
Action mit der Aktionskarte von Component . String -Konstante, die es dem Bootstrap-Code der Anwendung ermöglicht, das Action aus dem Component in "herauszunehmen" (z. B. um es zu JToolBar , JMenuBar usw. hinzuzufügen). updateActionStates() -Methode innerhalb der Component , die aufgerufen wird, wenn der Benutzer eine Aktion ausführt (z. B. wählt er N Zeilen aus JTable aus). Diese Methode aktiviert / deaktiviert alle maßgeschneiderten Aktionen basierend auf dem aktuellen Status von Component . Beispiel:
%Vor% Übrigens bevorzuge ich in der Regel Action s bis ActionListener s, um Action s offenzulegen, die Teil meiner Component API sind. Für Aktionen, die nur in Component existieren (z. B. die Schaltfläche "Löschen" eines Dialogfelds), verwende ich normalerweise ActionListener . Ich stimme jedoch nicht mit akf überein, da ActionListener der Standardansatz ist. Dies mag auf kleinere GUIs zutreffen, aber nicht auf komplexere Swing-Anwendungen.
Ich verwende Anmerkungen zu Aktionen und finde sie dann reflektiv.
Ein bisschen aufgeräumter und neue Aktionen werden automatisch verwaltet.
Tags und Links java user-interface swing action