OK, vielen herzlichen dank.
Nun bin ich wieder etwas klüger. :D
Man lernt ja nie aus. ;)

*oops* Zu früh abgeschickt...\n\n

<!--EDIT|BratHering|1133181731-->

Hallo! Die letzten Tage habe ich mit Nachdenken vebracht :D und bin zu einer Idee gekommen, wie man eine (so wie als ob) Document-View-Architektur in Perl aufbauen könnte. Hierzu hätte ich gerne die Meinungen von erfahrenen Perl Programmierern, denn ich bin nicht so sehr erfahren. ;)


Ich versuche es anhand des unteren groben Diagramms zu erklären:

Main.pl: Der Aufruf von Main.pl macht lediglich zwei "use" Aufrufe und sonst nichts (Module: Document.pm & View.pm). Eventuell nur noch einige Vorbereitungen im BEGIN Block und einige Nachbereitungen im END Block, also ja.

Document.pm: Zuerst wird das Modul Document.pm aufgerufen. Dies ist der Scope in dem sich alles rund um das "Document" drehen wird. Also d.h. Document.pm ruft die Klasse Doc.pm auf und bildet eine einzige Objekt-Instanz davon (das Objekt in dem sämtliche anwendungsspezifischen Dinge gespeichert werden / so wie es auch nur eine einzige Instanz von dem Document-Objekt in VisualC++ gibt). Danach wird das Modul Functions aufgerufen, dieses beinhaltet nur sub-Routinen die von der Anwendung nach aussen hin fungieren (sprich diese Funktionen sammeln alle Informationen z.B. aus der Windows-Registy oder aus irgendwelchen Dateien auf der Festplatte um diese im Document zu speichern).

Doc.pm: Dies ist die eigentliche Dokument-Klasse von der ein einziges Objekt in document.pm instanziiert wird. Es beinhaltet sämtliche Methoden, die für das Objekt notwendig sind. Das Objekt wird nur über die Methoden manipuliert.

Functions.pm: Dies sind die bereits o.g. Funktionen, die mit der Aussenwelt kommunizieren. Die Funktionen werden von Document.pm aus aufgerufen und die Rückgabewerte werden in dem Dokument-Objekt gespeichert. Functions.pm bildet aus den Informationen, die es bekommt, beliebig viele Objekte vom Typ Profile bzw. Mod, die dann die eigentlichen Rückgabewerte an den Document-Object-Container sind. Aber dies führt schon zu sehr auf meine Anendung hin.

View.pm: Dies ist das Modul für den View. Erst wenn Document.pm fertig und Fehlerfrei initialisiert worden ist, wird View.pm von Main.pl aufgerufen. Es beinhaltet die Tk-Forms und -Widgets. Auch "tkinit" und "MainLoop" befinden sich darin (ich habe es bereits ausprobiert und es scheint zu funktionieren). View.pm holt sich die nötigen Informationen zum Darstellen aus dem Dokument-Objekt und generell wird View selbst nur dazu benutzt den Inhalt aus dem Dokument-Objekt wiederzugeben und wenn Änderungen im Dokument-Objekt stattfinden, dann wird View sich über Callbacks aktualisieren. Dieses Callbacks.pm Modul wird vom View aus aufgerufen.

Calbacks.pm: Über diese Callbacks werden Änderungen am Dokument-Objekt vorgenommen und der View wird aktualisiert. Die Callbacks greifen aber nur auf Methden vom Dokument-Objekt (die schnittstelle des Objektes) zu.

z.B. könnte man das Modul Functions.pm weiter kapseln in Module die Funktionen für Datenbanken oder für Dateisysteme Zugriffe beinhalten. Auch den View könnte man noch weiter kapseln in Forms und Widgets, etc.


http://people.freenet.de/biteme/misc/DocumentViewA...


Oh mann, ich kann nur hoffen, dass jemand mich versteht? :D


MfG
BratHering

Nebenbei: eine Klasse bedeutet die Kapselung von Daten und Methoden, mit denen auf diese Daten zugegriffen wird. Von daher verstehe ich die Rolle von Functions.pm nicht, sondern wuerde diese als Methoden direkt in Document.pm legen.

zu main.pl:

in einem Modul sollte man meiner Meinung nach ausserhalb von Subroutinen keinen Code stehen haben (ausser vielleicht, wenn es sich um Konfiguration fuer dieses Modul handelt, oder ev. Caching-Variablen, auch wenn letztere meistens in einer eigenen Closure meist besser aufgehoben sind). Falls man dies doch tut, wird der Code ausgefuehrt, wenn das Modul geladen wird, und das kann leicht an der falschen Stelle sein. Ich bevorzuge den initialen Aufruf im Hauptprogramm, weil man dann genau sieht, wo es mit der Logik weitergeht, und man nicht bei 50 Modulen in jedem nachschauen muss, was denn da an Funktionalitaet direkt beim Laden ausgefuehrt wird. Sowas macht die Programmlogik naemlich ganz schoen undurchsichtig.

Ein Modul, das nur Funktionen bereitstellt, bietet sich dann an, wenn man die Funktionen in mehreren Modulen benoetigt. Ich benutze z.B. in meinem UML-Editor auch eine Actions.pm, die Funktionen bereitstellt, die von mehreren GUI-Elementen (Klassen) benoetigt werden...

UML-Editor? Ja gibts denn sowas für Perl? - Cool! - Wo gibbet dat?

Ist noch in der Mache. Ich hoffe, ich kann in diesem Jahr noch ne 1.0-Version bereitstellen. Das wird dann ein UML-Editor fuer Perl sein, mit dem man auch durch einfaches Importieren von Perl-Klassen bestehende Projekte modellieren kann... Aber dauert noch ein paar Wochen...

*gespanntwart* :)

[quote=BratHering,28.11.2005, 13:42]Main.pl: Der Aufruf von Main.pl macht lediglich zwei "use" Aufrufe und sonst nichts (Module: Document.pm & View.pm). Eventuell nur noch einige Vorbereitungen im BEGIN Block und einige Nachbereitungen im END Block, also ja.
[/quote]Natürlich sollte das Skript nicht Main.pl heißen, sondern <Applikation>, schließlich ist es das Programm, das aufgerufen wird. Und es sollte typischerweise einen Aufruf enthalten, siehe unten.

Quote

View.pm: Dies ist das Modul für den View. Erst wenn Document.pm fertig und Fehlerfrei initialisiert worden ist, wird View.pm von Main.pl aufgerufen. Es beinhaltet die Tk-Forms und -Widgets. Auch "tkinit" und "MainLoop" befinden sich darin (ich habe es bereits ausprobiert und es scheint zu funktionieren).

Aus ästhetischen und praktischen Gründen würde ich es vermeiden, Code in einer .pm-Datei auszuführen. Besser ist es, wenn du eine run-Methode oder so schreibst, wo tkinit ... MainLoop aufgerufen wird.

Zu deinem Strukturierungsvorschlag: ich strukturiere Tk-Programme selten. Mit einigen tausend Programmzeilen kann man in Tk sehr viel erreichen und kann trotzdem bei einer Skriptdatei bleiben und den Überblick behalten. Code wird bei mir ausgelagert, wenn das Programm verschiedene User Interfaces bekommt (Kommandozeile, GUI, CGI), wenn ich Funktionalität aus anderen Skripten heraus aufrufen will oder wenn ich Teile des Programms automatisiert testen will (GUI-Anwendungen lassen sich nicht so leicht testen).

Was aber immer gut kommt, ist das Erzeugen von Widgetklassen, die man ggfs. wiederverwenden kann.