[Ben]

Hi,
ich habe da mal eine etwas grundsätzlichere Frage.

Situation ist die Folgende:
Ich habe ein JInternalFrame mit einem Menü. In diesem Menü gibt es ein MenuItem mit der Beschriftung "Spiel starten".
Jut, was das machen soll ist glaube ich klar

Ich löse dort ja ein KeyEvent aus .. ich frage mich jetzt nur: "Wo fange ich das Ereignis ab?"

Meine Fragestellung bezieht sich auf die prinzipielle Strukturierung einer Anwendung.
MVC, alles schön und gut, allerdings finde ich diese 3-Klassen-Beispiele mehr als nur lächerlich und wenig produktiv.

Mir geht es darum, dass ich die Trennung so hinbekomme, dass ich auch verstehe, warum ich das jetzt eigentlich so gemacht habe.
Ich habe mir mehrere Packages angelegt.

Ganz oben liegt die Klasse StartApp.java. Hier liegt die main-Methode und somit der Start der Anwendung.
Dann kommt das Package "logic". Hier gibt es z.B. einen GameController, das Interface Game und weitere Klassen, die jetzt erstmal egal sind.

Im Package "ui" existieren derzeit nur zwei Klassen. Zum Einen die Klasse "DesktopFrame", welche das JInternalFrame und das Menü initialisiert und ein Kindfenster, welches ich mal "WelcomeFrame" genannt habe, da es sich nur um einen Test handelt.
Ich habe dort noch nicht mehr implementiert.

So. Jetzt habe ich weiterhin ein Subpackage "logic.flipper".
Hier liegt nun z.B. die Klasse "Ball" und die Klasse "FlipperController".
Im Subpackage "ui.flipper" liegen die Klassen "Barricade" und "Wall".

Soderle, das ist erstmal die Grundstruktur.

Wie denke ich derzeit, dass es laufen sollte?
Ich starte die Anwendung, danach initialisiere ich das grundsätzliche UserInterface und bin nun in der Lage ein Spiel zu starten.

Ich klicke also auf den Menü-Eintrag und es öffnet sich ein neues Kindfenster, welches den eigentlichen Flipper bzw. das eigentliche Spiel enthält.

Mann Ben, was ist denn nun die Frage?
1. Ist meine bisherige Strukturierung fehlerhaft?
2. Wo reagiere ich auf ausgelöste Events?
3. Greift der Controller auf eine Methode einer Klasse aus einem "ui"-Package zu, welche dann z.B. ein repaint() durchführt, oder würde das der MVC-Logik widersprechen?
4. ...

Gut. Ich habe eigentlich noch weitere Punkte, die mir unklar sind, allerdings schiebe ich die erstmal nach hinten. Das bringt sonst nichts

Wenn ich jetzt viel geredet habe und trotzdem Informationen nicht rübergekommen sind, dann fragt doch bitte nach.

Vielen Dank im Voraus.
Grüße Ben.

[pago]

"Ein Bild sagt mehr als tausend Worte" - wie wäre es also mit einem UML-Diagramm?

Bzgl. deiner Fragen:
1. Kann ich so nicht beurteilen. UML-Diagramm wäre gut.
2. Wie wäre es, wenn du in der entsprechenden Action-Klasse reagieren würdest?
3. Schätzungsweise nicht.

Kleiner Tipp: Eigentlich packt man alles in ein Hauptpackage. Per Standard entspricht das deiner Domain (bei mir z.B. "com.pagosoft" oder "org.simpleedit").
Also bei dir wäre das sowas in der art von "domain.appname.ui" usw.

[Ben]

DAS ist doch genau mein Problem.
Ich weiß halt nicht, wie ich das zeichnen soll. UML an sich .. kein Problem, aber ich weiß nicht welche Klassen untereinander kommunizieren müssen. Hm..

Ich weiß jetzt auch nicht wie ich das näher beschreiben soll ..

[`B]

dann poste doch einfach mal deinen Source dann kann man sich das anluxxen.

MVC ist nur in den ersten zwei-drei versuchen ein wenig schwer zu verstehen und macht bei sehr kleinen Anwendungen auch keinen wirklich Sinn.

Mal kurz umranden wie ich das nun lösen wird wenn ich das im Ansatz richtig verstanden habe was du suchst.

Also du hast einen HauptJFrame sozusagen die View vom MVC . Dieser hat dementsprechend einen Eventlistener welcher sich im Controller vom MVC wiederfindet. Ein neues JInternalFrame wird geöffnet. Welcher in sich eine komplette eigene Anwendung ist, dein Spiel. Also in sich eine eigenständige MVC-Instanz, welche durch ein Event im HauptJFrame gestartet wird.

So dein Spiel hat dann folgende Grundlegende Eigenschaften.

Eine View - also den JInternalFrame.
Ein Controller - er verwaltet die Ereignisse welche passieren können und leitet sie von der View zum entsprechenden Modell weiter und schickt das Ergebnis der Anfrage zurück an die View.

Bsp.: Du hast im JInternalFrame nur zwei JButtons.
1. Aufschrift bei jedem Klick die aktuelle Uhrzeit sein
2. Aufschrift vom ersten wird auf --:--:-- gesetzt.

Anwender klickt auf diesen Button (natürlich in der View). Diese leitet das Event weiter an den Controller. Der wertet aus, was ist da passiert. Wurde der erste Button geklickt oder der zweite? Beide geben verschiedene Events an den Controller. Ich löse so etwas mit Switch. zB. System.getProperty("lastButtonKlick"); und darin steht dann eine ID - zB. 1 - dazu gehört bei mir eine ordentliche Tabelle in den Kommentaren. Man kann es aber auch übersichtlicher mit If-Else lösen verbraucht aber mehr Platz. In dem Falle würd ich den JButtons dann auftragen JButton-UhrzeitAktuell und. JButton-UhrzeitClear.

So der Controller wertet das nun aus. Besitzt dabei sowohl die View als auch alle Modells. Bei mir sind diese in der Regel weitestgehend abstract so dass ich nicht alle von Beginn an initialisiern muss.

Somit schickt der Controller bei dem Event -JButton-UhrzeitAktuell eine Anfrage an die Klasse, nennen wir sie mal Uhrzeit, evtl. an eine direkte static String und bekommt somit einen passend formatierten String zurück, welcher dann direkt in der View mit Hilfe einer Methode oder durch das direkte Ansprechen des Objektes auf den JButton gesetzt wird.

Je umfrangreicher eine Anwendung wird, desto mehr Controller braucht diese in der Regel auch (zumindest bei mir). Ich filtere die Events dann direkt so, dass sie an den entsprechenden Controller als Anfrage weitergeleitet werden. Je Package das ich erzeuge habe ich meist einen Controller. Es sind halt immer einzelne an sich unabhängige Programmteile welche gewisse Aufgaben übernehmen.

Modells gibt es natürlich auch grenzenlos viele. Stell dir einfach vor, du schreibst einen Translator in jede Sprache. Dann hast du mind. 1 View wo oben der Text in Deutsch drin steht. Dann ein zweites Feld wo der übersetzte Text rein soll und n Button und ne Auswahlliste.

Anwender schreibt da nun was rein, wählt "Ugandarische Eingeborenensprache" aus und klickt auf Übersetzen.

Der Controller holt sich in dem Fall den zu übersetzenden Text bzw. bekommt ihn direkt mit übergeben und auch die ID der Sprache. Wählt dann das zur Sprache entsprechende Modell stellt die Übersetzungsanfrage und aktualisiert die View. Bei der Masse an Sprachen also auch massig viele Modells. Könnte man nun auch verteilen in mehrere Packages. - zB Europa, Afrika, Asien, Amerika, Australien oder nach Alphabet oder kA wie. Es macht nunmal meine Meinung nach Sinn den Umfang eines Package überschaubar zu halten. Aber ich denke das ist einfach Ansichtssache.

Hoffe dir weitergeholfen zu haben.

Grüße

Florian

[Ben]

Hi,
also ... ähm, das ist jetzt irgendwie ein Mix aus dem Thread hier und diesem da:
--> http://www.jforum.de/showthread.php?t=1381

Ich stelle die Frage nun hier, weil ich jetzt vom zum Controller komme und da passt es hier irgendwie besser

Also. Ich habe nun ein Menü nach diesem Schema hier erstellt:

PHP-Code:

menu = new JMenu("Erfassen");
menu.setMnemonic(KeyEvent.VK_E);
menuBar.add(menu);

// Einträge des Menüs 
menu.add(new RecordInputDataAction());
menu.add(new RecordOutputDataAction()); 


Die beiden Klassen implementieren natürlich die Methode actionPerformed(ActionEvent).

Ok. In dieser Methode wird jetzt ja irgendwie die jeweilige Aktion angesprochen bzw. ausgeführt.
Meine Frage ist jetzt:
"Brauche ich jetzt einen Controller, der die "Actions" irgendwie weiterleitet oder rufe ich die Sachen direkt auf?

Frage ist weiterhin:
"Egal wer jetzt letztendlich die Funktionalität anspricht ... wie strukturiere ich jetzt den Controller?"

Das hört sich jetzt irgendwie an, als ob ich mich nicht auch außerhalb dieses Threads damit beschäftigt habe, aber das entspricht nicht der Tatsache. Ich brauche einfach noch den Tick. :rolleyes:

Das hier

Zitat von `B

Je umfrangreicher eine Anwendung wird, desto mehr Controller braucht diese in der Regel auch (zumindest bei mir). Ich filtere die Events dann direkt so, dass sie an den entsprechenden Controller als Anfrage weitergeleitet werden. Je Package das ich erzeuge habe ich meist einen Controller. Es sind halt immer einzelne an sich unabhängige Programmteile welche gewisse Aufgaben übernehmen.

ist mir vom Prinzip schon klar, allerdings frage ich mich eben, wie denn so ein Controller dann im Endeffekt aussieht.

Könnte mir das eventuell noch mal jemand näher bringen?
Ich danke Euch.

Grüße Ben.

[Ben]

Ich schreibe das mal als extra Posting, weil ich eventuell noch darauf verlinken will. Sorry für das Doppelposting


So. Ich erweitere mal etwas die Frage- bzw. Problemstellung.
Ich habe nun den Menüeintrag

Erfassen -> Wareneingang

Ich habe mein Beispiel abgeändert. Ich bastel mir mal etwas mit Eingabe, Bearbeitungsmöglichkeit und Anzeige, damit ich das alles ein bisschen schneller verinnerliche

Jut.
In der Methode actionPerformed() in der Klasse RecordInputDataAction müsste ich nun ja irgendwie eine Anzeige eines Formulars oder so ansprechen.

Und genau das ist jetzt mein Problem. Ich weiß nicht, wie ich das strukturiere.
Schreibe ich einfach einen Aufruf einer entsprechenden Methode showInputForm() oder wie mache ich das?

Frage ist dann direkt:
"Wo wäre denn dann diese Methode überhaupt? Also in welcher Klasse wäre sie implementiert?"

Im ersten Ansatz würde ich jetzt denken, dass es pro Klasse im Package ui auch eine Klasse im Package logic geben muss.
Dann denke ich aber, dass man ja auch eine Klasse schreiben könnte, die den gesamten Anzeigekram des Wareneingangs regelt. Also das Formular anzeigt, die Bestätigung, etc. etc.

Und dazu dann eine entsprechende "Controller"-Klasse, welche je nach "Action" bzw. Aufruf etwas ausführt.

Ich möchte hier jetzt aber auch nicht wild drauf losprogrammieren ohne zu wissen, ob der Ansatz "richtig" bzw. akzeptabel ist.

An der Technik wird es wohl eher nicht liegen .. eher an der Vorabplanung.

Danke nochmals.
Grüße Ben.

[nove]

kleine Zwischenbemerkung :

ich finde das Thema höchstinteressant und ist nachdem Ben all seine Probleme gelöst hat denke ich Wert als so eine Art Guide ausgearbeitet zu werden.

[Ben]

Also ich kann jetzt gerade mal etwas zu dieser Zwischenbemerkung sagen

Es ist so, dass es hier anscheinend keine Musterlösung für gibt.
Das ist meiner Ansicht nach optimal , da man so nicht sagen kann "Du machst das richtig bzw. falsch".

Ich habe nun den Ansatz von TheDragonMaster weiterverfolgt, d.h. ich schreibe "Action"-Klassen, welche ich dann z.B. dem Menü zuweise. Allerdings steht es mir ja frei diese auch Buttons oder was weiß ich nicht noch alles zuzuweisen.

Jut. Jetzt war mein nächstes Problem, dass ich nicht genau wusste, wie ich "den Controller" schreiben sollte. Ich sehe jetzt "jede" "Action"-Klasse, die am Model rumändert als Controller an.

In der "actionPerformed()" der Klasse RecordInputDataAction werden nun also die entsprechenden Methoden aufgerufen, um das zu machen, was sich hinter dem Menüpunkt bzw. generell hinter der Aktion verbirgt.

Mir war zuerst nicht klar, wie die drei Parteien miteinander kommunizieren.

Der Controller reagiert auf ein Event, welches im View ausgelöst wird. Dies geschieht in meinem Fall jetzt erstmal mit der actionPerformed().
Je nach "Action" wird dann das Model geupdated. Ist diese Aktualisierung im Model erfolgt löst das Model einen PropertyChangeEvent aus.
Der View wiederum nutzt den entsprechenden Listener, um genau auf diese Events zu achten und refreshed sich sozusagen selbst, wenn das Model aktualisiert wurde.

So sollte das jetzt stimmen .. *hoff*

Jut.
Mein Problem dabei ist jetzt, dass ich nicht genau weiß, wie man mit den ganzen Models umgeht, die Java schon mitbringt.

Für eine Anzeige würde ich eine Klasse schreiben, die z.B. das AbstractTableModel implementiert oder so. Habe ich mich jetzt noch nicht genau mit befasst.
Da könnte ich dann eine dieser Methoden hier verwenden:
--> http://java.sun.com/j2se/1.5.0/docs/...ean,%20boolean)

Jo.
Aber jetzt mal ein anderer Fall.
Ich möchte Daten in einem Formular eingeben.

Ich klicke also auf "Erfassen -> Wareneingang".
Ok. Die Methode "actionPerformed()" der Klasse ReportInputDataAction wird aufgerufen.
So. Jetzt muss ich ja, wie oben beschrieben, das Model kontaktieren. Aber was genau mach ich denn jetzt?

Ich habe hier gesehen, dass ja auch nicht einfach überall die Methode firePropertyChange gibt.

Ich habe das Prinzip glaube ich fast verstanden .. auf jeden Fall nähere ich mich. GLAUBE ICH

Bitte noch etwas schubsen .. Danke