ich möchte einen komplexeren baum zeichnen. es gibt knoten, die wiederum kinderknoten haben. die verbindungen zwischen den knoten sollen ebenfalls grafisch dargestellt werden. die darstellung einzelner knoten ist recht aufwändig, da innerhalb dieser knoten wieder weitere objekte (--> also weitere JComponents) dargestellt werden müssen, wobei hier auch die anzahl variiert.
mir gehts es nun um das design im hinblick auf das MVC-pattern (worüber ich nicht viel weiß/wusste - ich kannte nur den grundsatz, GUI von BusinessLogic zu trennen). Nun habe ich mir mal diesen guide (http://java.sun.com/products/jfc/tsc/articles/architecture/#modified_mvc) durchgelesen (allerdings nicht alles über LookAndFeel) und auch hier im Forum ein wenig gesucht. mir ist jedoch noch einiges unklar.
1. sollte man den Controller (in der regel) nun vom View trennen (--> eigene klassen) oder nicht. für mich bietet es sich allein der übersichtlichkeit wegen an, weil die von JPanel abgeleitete klasse TreePanel, die den Baum zeichnet, groß geworden ist und ich ne eigene Controller-Klasse gemacht habe, die Action/MouseListener für TreePanel spielt und befehle an das model weiterleitet.
also ich denke, dass dies okay ist, auch wenn im SwingMVC oft keine Trennung zwischen View und Controller besteht (wenn ich das richtig verstanden habe).
2. mein design funktionierte bisher so, dass die hauptklasse der businesslogic, ich nenne sie mal TreeModel (aber nicht das TreeModel aus der JavaApi) der GUI, also TreePanel, ganz genau sagte, was sie zu tun hat. also zb.:
addNode(Node newNode, Node parentNode);
gemäß swing-MVC werde ich das jetzt umdrehen:
TreePanel kennt Model und nicht umgekehrt. TreePanel implementiert TreeModelListener und added sich als Listener beim TreeModel. das Model bzw. die BusinessLogic sagt dem Listener nur, dass sich etwas geändert hat bzw auch was genau (--> stateful notification), aber es gibt keine befehle à la deleteNode(Node). stattdessen gibts nur ne notification, dass der node gelöscht wurde.
das würde MVC entsprechen, richtig?
3. da die einzelnen knoten wie gesagt komplex sind und nicht nur ein punkt/kreis, sollte ich das wohl analog zum treepanel machen: die Node-Datenobjekte in der BusinessLogic sollten bei änderungen ihre nodelistener informieren. nodelistener wird das nodepanel sein, das die darstellung eines knotens übernimmt.
--> für alle komplexeren objekte model + view machen?
4. das baum-model sieht so aus, dass jeder knoten referenzen zu seinen kinderknoten hat. die verbindungsinformation ist also teil eines Node-Objekts. in der GUI gehört die verbindungsinformation aber nicht zum View des Knoten, also NodePanel, sondern zum TreePanel. (denn die verbinundslinie wird ja zwischen den knoten gezeichnet, also im treepanel)
wie soll ich das nun lösen?
1. treepanel implementiert NodeModelListener und lässt sich ebenfalls über änderungen von nodes informieren(interessiert sich aber nur für verbindungsänderungen)
2. treemodel implementiert NodeModelListener und informiert dann über diesen Umweg TreePanel.
3. eine eigene klasse NodeConnectionModel, diese added sich als listener bei NodeModels und informiert TreePanel, das sich als NodeConnectionModelListener beim NodeConnectionModel geaddet hat, bei veränderungen.
nummer 3 scheint mir am aufwändigsten aber auch am flexibelsten für die zukunft. könnte ja zb auch sein, dass die daten anders gespeichert sind und es ein "echtes" treemodel gibt.
5. wie sieht es mit den controllern aus? soll es da auch ne hierarchie geben?
das problem ist im gegensatz zur reinen darstellung, dass es hier ja nicht nur um das eine model bzw. um den einen controller geht, denn zb kann man sich zu einem knoten ein kontextmenü anzeigen lassen. der inhalt dieses kontextmenüs ist aber abhängig von früheren befehlen (also zb, ob ein anderer knoten bereits selektiert ist).
--> entweder ich habe nur einen übergeordneten controller, der alles koordiniert oder jeder node (und eventuell auch objekte in den nodes), kriegen einen. Diese müssten dann aber entweder informiert werden über den aktuellen Stand der Dinge oder Aktionen, die nicht 100% nur den einen JComponent betreffen, müssten in der controllerhierarchie weitergeleitet werden. --> ein controller kennt seinen parent controller. (ist das üblich?)
(eine weitere möglichkeit wäre wohl, dass ich aktuelle aktionen (also zb eine selektion eines knoten) schon in das model schreibe. treemodel würde dann also den selektierten knoten kennen. ich denke aber, dass erst fertig eingegebene befehle vom controller an das model weitergeleitet werden sollten)
ich denke mir, dass in den meisten fällen nur der übergeordnete Controller einen befehl verarbeiten wird und somit ein einzelner controller ausreichen würde. andererseits könnte ich mir vorstellen, dass man zb bei einem nodepanel die interne darstellung des nodes wechseln können möchte. das betrifft dann nur einen knoten und davon sollte der treecontroller eigentlich nix mitbekommen...
--> gehe ich recht in der annahme, dass es hier einfach stark darauf ankommen wird, wieviel funktionalität ich benötigen werde?
ich hoffe, dass irgendjemand die zeit hat sich das durchzulesen und eventuell ein paar tipps hat
danke schon mal!
mir gehts es nun um das design im hinblick auf das MVC-pattern (worüber ich nicht viel weiß/wusste - ich kannte nur den grundsatz, GUI von BusinessLogic zu trennen). Nun habe ich mir mal diesen guide (http://java.sun.com/products/jfc/tsc/articles/architecture/#modified_mvc) durchgelesen (allerdings nicht alles über LookAndFeel) und auch hier im Forum ein wenig gesucht. mir ist jedoch noch einiges unklar.
1. sollte man den Controller (in der regel) nun vom View trennen (--> eigene klassen) oder nicht. für mich bietet es sich allein der übersichtlichkeit wegen an, weil die von JPanel abgeleitete klasse TreePanel, die den Baum zeichnet, groß geworden ist und ich ne eigene Controller-Klasse gemacht habe, die Action/MouseListener für TreePanel spielt und befehle an das model weiterleitet.
also ich denke, dass dies okay ist, auch wenn im SwingMVC oft keine Trennung zwischen View und Controller besteht (wenn ich das richtig verstanden habe).
2. mein design funktionierte bisher so, dass die hauptklasse der businesslogic, ich nenne sie mal TreeModel (aber nicht das TreeModel aus der JavaApi) der GUI, also TreePanel, ganz genau sagte, was sie zu tun hat. also zb.:
addNode(Node newNode, Node parentNode);
gemäß swing-MVC werde ich das jetzt umdrehen:
TreePanel kennt Model und nicht umgekehrt. TreePanel implementiert TreeModelListener und added sich als Listener beim TreeModel. das Model bzw. die BusinessLogic sagt dem Listener nur, dass sich etwas geändert hat bzw auch was genau (--> stateful notification), aber es gibt keine befehle à la deleteNode(Node). stattdessen gibts nur ne notification, dass der node gelöscht wurde.
das würde MVC entsprechen, richtig?
3. da die einzelnen knoten wie gesagt komplex sind und nicht nur ein punkt/kreis, sollte ich das wohl analog zum treepanel machen: die Node-Datenobjekte in der BusinessLogic sollten bei änderungen ihre nodelistener informieren. nodelistener wird das nodepanel sein, das die darstellung eines knotens übernimmt.
--> für alle komplexeren objekte model + view machen?
4. das baum-model sieht so aus, dass jeder knoten referenzen zu seinen kinderknoten hat. die verbindungsinformation ist also teil eines Node-Objekts. in der GUI gehört die verbindungsinformation aber nicht zum View des Knoten, also NodePanel, sondern zum TreePanel. (denn die verbinundslinie wird ja zwischen den knoten gezeichnet, also im treepanel)
wie soll ich das nun lösen?
1. treepanel implementiert NodeModelListener und lässt sich ebenfalls über änderungen von nodes informieren(interessiert sich aber nur für verbindungsänderungen)
2. treemodel implementiert NodeModelListener und informiert dann über diesen Umweg TreePanel.
3. eine eigene klasse NodeConnectionModel, diese added sich als listener bei NodeModels und informiert TreePanel, das sich als NodeConnectionModelListener beim NodeConnectionModel geaddet hat, bei veränderungen.
nummer 3 scheint mir am aufwändigsten aber auch am flexibelsten für die zukunft. könnte ja zb auch sein, dass die daten anders gespeichert sind und es ein "echtes" treemodel gibt.
5. wie sieht es mit den controllern aus? soll es da auch ne hierarchie geben?
das problem ist im gegensatz zur reinen darstellung, dass es hier ja nicht nur um das eine model bzw. um den einen controller geht, denn zb kann man sich zu einem knoten ein kontextmenü anzeigen lassen. der inhalt dieses kontextmenüs ist aber abhängig von früheren befehlen (also zb, ob ein anderer knoten bereits selektiert ist).
--> entweder ich habe nur einen übergeordneten controller, der alles koordiniert oder jeder node (und eventuell auch objekte in den nodes), kriegen einen. Diese müssten dann aber entweder informiert werden über den aktuellen Stand der Dinge oder Aktionen, die nicht 100% nur den einen JComponent betreffen, müssten in der controllerhierarchie weitergeleitet werden. --> ein controller kennt seinen parent controller. (ist das üblich?)
(eine weitere möglichkeit wäre wohl, dass ich aktuelle aktionen (also zb eine selektion eines knoten) schon in das model schreibe. treemodel würde dann also den selektierten knoten kennen. ich denke aber, dass erst fertig eingegebene befehle vom controller an das model weitergeleitet werden sollten)
ich denke mir, dass in den meisten fällen nur der übergeordnete Controller einen befehl verarbeiten wird und somit ein einzelner controller ausreichen würde. andererseits könnte ich mir vorstellen, dass man zb bei einem nodepanel die interne darstellung des nodes wechseln können möchte. das betrifft dann nur einen knoten und davon sollte der treecontroller eigentlich nix mitbekommen...
--> gehe ich recht in der annahme, dass es hier einfach stark darauf ankommen wird, wieviel funktionalität ich benötigen werde?
ich hoffe, dass irgendjemand die zeit hat sich das durchzulesen und eventuell ein paar tipps hat
danke schon mal!
