text/thesis.troff

@@ -41,26 +41,31 @@ Die vorliegende Software ist in Java geschrieben und arbeitet stark mit Objektor
 Der gesamte Code der Anwendung befindet sich im Paket \fChsmw.jotto5.beleg\fR. Direkt in diesem Paket befindet sich die Main-Klasse mit dem Einstiegspunkt. Darunter befindet sich das Paket \fCviews\fR, in dem die Klassen für die einzelnen Views liegen, und das Paket \fCdata\fR, in dem alle Klassen implementiert sind die sich mit Datenverwaltung und Abfrage beschäftigen, zum Beispiel das Model.
 
 .H3 Datenverwaltung
-Die zentrale Klasse der Datenverwaltung ist die abstrakte Klasse \fCDataObject\fR. Sie stellt die Superklasse für alle im Model verwalteten Objekte dar. Ihre Implementation ist bewusst sehr einfach gehalten.
+Die zentrale Klasse der Datenverwaltung ist die Klasse \fCDataObject\fR. Sie stellt die Superklasse für alle im Model verwalteten Objekte dar. Ihre Implementation ist sehr einfach gehalten.
 .sp
 .TS
-box center;
+tab(;) box center;
 cb
 -
 l
 l
+l
 -
 l.
 DataObject
-+ displayName: String
-+ uid: String
+# model: Model
+# uid: String
+# displayName: String
 # DataObject(String uid, String displayName)
+# setModel(Model): void
++ getModel(): Model
++ getDisplayName(): String
++ setDisplayName(String displayName): void
 .TE
 .sp
-Die UID ist ein String, welcher eine eineindeutige Zeichenkette für das Objekt enthält. Strukturiert werden kann sie als Hierarchie mit / als Trennzeichen, zum Beispiel \fCstudents/jotto5\fR. Das ist nicht benötigt, aber einige Views verwenden diese Syntax für eine etwas bessere Übersicht. Der DisplayName ist ein frei wählbarer String welcher einen menschenlesbare Namen für das Objekt enthält, im Fall einer Studierenden Person zum Beispiel eine Zeichenkette im Format \fCVorname, Nachname\fR.
+Das DataObject behält selber eine Referenz auf das Model zu dem es gehört. Die UID ist ein String, welcher eine eineindeutige Zeichenkette für das Objekt enthält. Strukturiert werden kann sie als Hierarchie mit / als Trennzeichen, zum Beispiel \fCstudents/jotto5\fR. Das ist nicht benötigt, aber einige Views verwenden diese Syntax für eine etwas bessere Übersicht. Der DisplayName ist ein frei wählbarer String welcher einen menschenlesbare Namen für das Objekt enthält, im Fall einer Studierenden Person zum Beispiel eine Zeichenkette im Format \fCVorname, Nachname\fR.
 
-Die Klasse enthält einen Konstruktor der die UID und den Anzeigenamen initialisiert. Dieser ist bewusst protected gehalten, da die DataObject-Klasse abstrakt ist und nur als Superklasse dient. Setter und Getter sind nicht vorgesehen, da die Felder public sein müssen.
-.TODO Referenz auf Formular-Annotation-System!\"
+Die Klasse enthält einen Konstruktor der die UID und den Anzeigenamen initialisiert. Dieser ist bewusst protected gehalten, da die DataObject-Klasse selber nicht instanziiert werden soll und nur als Superklasse dient. Der Setter für das Model ist nur aus dem Model zu verwenden und daher protected.
 
 Von dem DataObject erben nun mehrere Klassen, welche spezifischere Felder und Methoden beinhalten können, zum Beispiel die Klasse \fCStudent\fR oder die Klasse \fCGroup\fR. Das hat den Vorteil dass das Model selber sich nur um die Verwaltung einer Liste von DataObjects kümmern muss ohne die genaue Semantik zu kennen oder eine Trennung zwischen verschiedenen Typen machen zu müssen. Für das Verwenden der Objekte werden dann Javas Möglichkeiten der Reflexion bzw. Introspektion benutzt.
 
@@ -70,8 +75,8 @@ Der Webserver selber ist mithilfe der Bibliotheken aus dem JDK entwickelt, und n
 
 Die Views selber befinden sich als einzelne Klassen im Paket \fChsmw.jotto5.beleg.views\fR. Sie erben von \fCcom.sun.net.httpserver.HttpHandler\fR und implementieren ihre \fChandle\fR-Methode. Diese Methode wird aufgerufen wenn der an die View gebundene Endpunkt angefragt wird, und verarbeitet einen als Argument übergebenen \fCHttpExchange\fR.
 
-Manche Views bieten interaktive Möglichkeiten an, zum Beispiel Formulare. Diese Views prüfen bei jedem Aufruf den HTTP-Anfragetyp. Bei einer GET-Anfrage wird einfach nur das Formular zurückgegeben. Wenn die benutzende Person ein Formular abschickt wird es als POST-Request übergeben, in diesem Fall führt die View Logik zum Bearbeiten des Models aus.
+Manche Views bieten interaktive Möglichkeiten an, zum Beispiel Formulare. Diese Views prüfen bei jedem Aufruf den Http-Anfragetyp. Bei einer GET-Anfrage wird einfach nur das Formular zurückgegeben. Wenn die benutzende Person ein Formular abschickt wird es als POST-Request übergeben, in diesem Fall führt die View Logik zum Bearbeiten des Models aus.
 
-In der Regel ist jede View für genau einen Endpunkt zuständig. Die RootView ist eine Ausnahme. Sie wird auch für alle nicht zugeordneten Endpunkte aufgerufen. In diesem Fall prüft die RootView nach einer Datei mit dem angefragten Namen im Ordner \fCstatic\fR. Das wird zum Beispiel für CSS-Stylesheets und Bilder verwendet. Wenn es keine Datei mit dem Namen gibt wird schlussendlich ein HTTP-404-Fehler geworfen.
+In der Regel ist jede View für genau einen Endpunkt zuständig. Die RootView ist eine Ausnahme. Sie wird auch für alle nicht zugeordneten Endpunkte aufgerufen. In diesem Fall prüft die RootView nach einer Datei mit dem angefragten Namen im Ordner \fCstatic\fR. Das wird zum Beispiel für CSS-Stylesheets und Bilder verwendet. Wenn es keine Datei mit dem Namen gibt wird schlussendlich ein Http-404-Fehler geworfen.
 
 Besonders ist auch die Klasse \fChsmw.jotto5.beleg.views.Defaults\fR. Sie stellt selber keine View dar, bietet aber statische Methoden und Variablen an welche zwischen allen Views geteilt werden, zum Beispiel ein Grundgerüst für die HTML-Dokumente welche zurückgegeben werden.