Mein letzter Blogeintrag OOP in LS: MVC in Lotus
Notes hörte mit dem Versprechen auf, näher auf die Trennung
zwischen Frontend und Backend und die Verwendung von Controllerklassen
einzugehen.
Das zugrundeliegende Ziel bei der Verwendung
von Controllerklassen, um auf die Fachklassen zuzugreifen, ist die Umsetzung
aller fachlichen Anforderungen nur an einer Stelle im Code.
Wenn also die fachliche Anforderung z.B.
gewisse Pflichtfelder vorzieht, so wird die Definition der Pflichtfelder
nur in der Fachklasse vorgenommen. Der entscheidene Vorteil in diesem Vorgehen
besteht in einer höheren Wartbarkeit. Wenn sich die Anforderungen mal ändern
sollten (was ab und zu mal vorgekommen sein soll ), dann wird die neue
Anforderung auch nur an einer Stelle umgesetzt.
Der Vorteil wird spätestens dann deutlich,
wenn neben dem Notes Client auch Eingaben per Web Browser erfolgen. Die
Praxis hat gezeigt, dass für eine optimale Umsetzung zwei Masken notwendig
sind. Nur so kann in beiden Welten eine optimale Darstellung gewährleistet
werden. Statt nun zu versuchen, die Eingabevalidierung in beiden Masken
gleich zu halten, greifen die Masken über ihre jeweiligen Controllerklassen
auf die Fachklasse zu.
Es muss unterschiedliche Controllerklassen
für den Notes Client und den Browser geben, weil in beiden unterschiedliche
Events gibt, auf die mit einem Zugriff auf die Fachklasse reagiert werden
muss. Zum Beispiel kann bei der Eingabevalidierung im Notes Client beim
QuerySave-Event die Gültigkeit überprüft werden. Im Web Browser gibt es
zwar mit dem OnSubmit-Event in JavaScript auch ein Event, dass vergleichbar
dem QuerySave ist. Jedoch kann dort nicht direkt LotusScript ausgeführt
werden. Außerdem kann JavaScript im Browser abgeschaltet sein, so dass
man um eine weitere Überprüfung auf dem Server nicht herum kommt.
Selbstverständlich gelten die Anforderungen
aus der Fachwelt auch dann, wenn z.B. ein Dokument durch einen zeitgesteuerten
Agenten verändert wird. Der Agent greift direkt auf die Fachklasse direkt
zu. In dem Fall kann auf einen Controller verzichtet werden, weil es keine
Events gibt, auf die reagiert werden müsste.
Damit die Fachklasse von jedem Kontext
aus verwendet werden kann, dürfen keine Notes UI-Methoden oder -Klassen
wie z.B. NotesUIWorkspace oder NotesUIDocument verwendet werden. Der Grund
für diese Einschränkung liegt darin, dass z.B. zeitgesteuerte Agent und
WebQuerySave-Agents nicht ausgeführt werden, wenn Notes UI-Klassen im Code
referenziert werden. Der Verzicht auf Notes UI-Klassen in der Fachklasse
ist insofern keine Einschränkung, weil die Controllerklasse für den Notes
Client alle Aufgaben übernimmt, die mit diesen Klassen zu tun haben.
In den nächsten Blog-Einträge werden
Basisklassen für Model und Controller vorgestellt, von denen die konkreten
Klassen abgeleitet werden können.