Swing-Frontend abhängig von ausgewähltem Objekt

[muckelzwerg]

Hey, folgende Situation.
Ich habe eine Swing-Oberfläche mit der ich den Zustand verschiedener Objekte anzeige. Die Objekte werden über einen JTree ausgewählt.
Diese Objekte haben verschiedene "Debug-Funktionen". Diese Funktionen sollen nun in der Oberfläche zur Verfügung gestellt werden.
Ich habe bspw. ein Objekt "IR-Camera", welches die Funktion "calibrate()" anbietet. Diese Funktion/Methode soll im Frontend als Button angeboten werden. Was dann weiter passiert ist erstmal offen.

- Die Objekte sollen eigentlich keine Swing-Funktionalität besitzen. Ein "zeichne hier deine objektspezifischen Steuerelemente" soll nicht sein. Wenn überhaupt müssen die Funktionen von außen ermittelt und dann entsprechende Elemente erzeugt werden.

- Der Objekttyp entscheidet zwar, welche Funktionen angeboten werden, allerdings müssen das nicht unbedingt alles Methoden der Objekte sein. Es kann also z.B. sein, dass die Funktion "calibrate()" nicht vom Kameraobjekt ausgeführt wird, sondern von einem anderen Objekt (welches der Kamera nicht bekannt ist) und die Kamera letztlich nur ein Parameter ist.
Insofern wäre da vielleicht ein Lösung über Wraper, oder Dekorationen eine gute Idee.

Hat jemand Ideen? (Bin kein Swing-Profi, kann also gut sein, dass ich was Naheliegendes übersehen habe.)

 

[Marco13]

Mehr als "Kommt drauf an...." kann man da kaum sagen. Nach welchen Kriterien (und wann und wo) wird denn entschieden, welche Funktionen da im GUI zu sehen sein sollen?

 

[muckelzwerg]

Also ich denke, dass ich es nahezu 100% vom Objekttyp abhängig machen kann.
Ich könnte also eine oder mehrere Klassen schreiben, in denen das Wissen über die "Sonderfunktionen" einer oder mehrere Klassen gespeichert ist.

Schön wäre natürlich wenn es auch instanzabhängig ginge und die Objekte z.B. ein paar einfache Methoden ohne zusätzliche Dialoge oder Rückgabewerte auch selbst anbieten könnten.
Eine Kamera könnte z.B. eine Funktion "reset()" oder "stop()" anbieten, weil eben genau diese eine Kamera das kann.
Oder vielleicht eine Funktion "rotate()", weil genau diese Kamera einen Motor besitzt.
Daraus sollte dann im Frontend lediglich ein einzelner Knopf werden, der die Funktion ausführt.
Diese Funktionen müssen nur irgendwie aus den Objekten "rausgesucht" und z.B. in JButtons umgesetzt werden.
"Wie?" ist die Frage.

Demgegenüber kann mit jeder Kamera "calibrate()" ausgeführt werden. Da wird dann vermutlich ein Dialog aufgehen, der erstmal die Art der Kalibration erfragt. Das ist also schon viel zu viel "Zeug", was nicht mehr in die Kameraklasse gehört.
Da könnte wie gesagt ein "Wrapper" verwendet werden, der jedes Kameraobjekt kapselt und pauschal diese und andere Funktionen anbietet.


Aber so richtig glücklich bin ich mit keiner Vorstellung. Ich will nicht, dass eine Kameraklasse Swing-Code enthält. Ich will aber auch nicht unbedingt alle Klassen "doppelt" schreiben müssen, nur um da eine Trennung zu erzeugen.
Ich hatte kurz gedacht, man könnte es über die Rendererklassen machen. So wie man einen CellRenderer überschreibt.
Der könnte ja den Typ prüfen und dann den Standardumfang an Funktionen selbst hinzufügen (oder delegieren).
Ich wüsste aber jetzt keine Komponente, in die man das schön reingefummelt bekommt.
Die Objekte werden in einer JTable angezeigt. Ich könnte theoretisch Funktionen anbieten, indem ich bestimmte Felder dann mit JButtons fülle. Aber ist das cool?

 

[Marco13]

So ganz ist mir nicht klar, worum es geht. Erstmal vorneweg: Natürlich sollten die Klassen, die eigentlich nichts mit Swing zu tun haben (sondern nur im Moment zufällig von einer Swing-GUI gesteuert werden sollen) keinen Swing-Code enthalten.
Ansonsten... könnte es sowas wie eine
interface ControlDialog { void setControlledObject(Object x); }
Map<Class<?>, ControlDialog> dialogs = ...
geben, wo für jede Objektart die passenden Dialoge drinliegen.

Man kann auch automatisch die angebotenen Methoden raussuchen, z.B. mit reflection, aber welche davon im GUI angeboten werden sollen, weiß man ja nicht.

Ein Beispiel:

class Camera
{
    void calibrate() { ... }
    void move(float x) { ... }
    void doSomethingSecret() { ... }
    void process(List<Camera> others) { ... }
}

Wer soll wo wann bestimmen, dass man einen Button für "calibrate" haben soll, und einen Slider für "move(x)", und sonst nichts?

 

[muckelzwerg]

Das ganze ist auch mir noch nicht so 100% klar.
Ich habe irgendwo ein Panel, innerhalb dessen die Daten und Schaltflächen des aktuellen Objekts liegen.
Da werde ich jetzt erstmal generische Schaltflächen einbauen, die abhängig vom Objekttyp angeboten werden oder nicht.
Da entscheidet die Frontendklasse dann selbst, ob sie für das Objekt zusätzliche Elemente hinzufügen kann, oder nicht.

Für Frontendfunktionen, die von den Objekten selbst angeboten werden, warte ich mal ab, wie sich der erste Teil entwickelt.
Evtl. rutscht das sogar in Richtung Webservice-Frontend generieren ab und da hab ich grad null bock drauf.