Als Alternative zu einem völlig neuen Theme besteht auch die Möglichkeit ein vorhandenes Theme zu erweitern.
Dafür muss man unter dem 'WEB-INF/lib/' Verzeichnis des Projekts ein Verzeichnis 'themes' erstellen, in das alle Themes (neue bzw. erweitere) in eigene Unterverzeichnisse kommen. In einem solchen Theme-Verzeichnis (zum Beispiel 'WEB-INF/lib/themes/extended' für ein erweitertes Theme) muss sich eine XML-Datei mit dem Namen 'description.xml' befinden.
Der Inhalt dieser Datei wird mittels folgendem Muster erstellt:
Beginn description.xml
---<?xml version="1.0" encoding="UTF-8"?>
<theme name="NameDesTheme">
Dieser Name muss der des Theme-Verzeichnisses sein (zum Beispiel 'extended').
<extends theme="default"/>
Bezeichnet den Namen des Theme, das erweitert werden soll.
<description>My Extended Theme</description>
Beschreibung für das Theme (beliebiger Text).
<author name="Your name" email="you@the.web" />
Autor des Theme (beliebiger Text).
Der folgende Abschnitt (von '<fileset>' bis '</fileset>') wird nur benötigt, falls im Theme XSL-Transformationsdateien vorkommen (sollte nur das CascadingStyleSheet angepasst werden kann dieser Abschnitt weggelassen werden). Werden
XSL-Transformationsdateien verwendet muss für jede Datei eine '<file name="Unterverzeichnis/Dateiname.xsl" />'-Zeile eingetragen werden, wobei 'Dateiname.xsl' natürlich mit dem Dateinamen der jeweiligen Datei zu ersetzen ist.
'Unterverzeichnis' ist mit der jeweiligen Unterverzeichnis-Struktur zu ersetzen (ohne führenden Schrägstrich). Man startet dabei im Verzeichnis des Theme.
Ist also das Theme unter 'WEB-INF/lib/themes/extended' zu finden und die XSL-Transformationsdateie 'MeineUIKomponente.xsl' (für die
Benutzerschnittstellen-Komponente 'MeineUIKomponente.java') unter
'WEB-INF/lib/themes/extended/xsl/basic/', dann lautet die Unterverzeichnis-Struktur
'xsl/basic/' und somit ist die Zeile '<file
name="xsl/basic/MeineUIKomponente.xsl" />' einzufügen.
<fileset>
<file name="myOwnXsl_1.xsl" />
<file name="subdir/myOwnXsl_2.xsl" />
</fileset>
</theme>
Ende description.xml
---Will man nun beispielsweise das optische Erscheinungsbild der Benutzerschnittstellen-Komponenten des Standard Theme anpassen, so muss man nur das Theme 'default' – wie oben beschrieben – erweitern und man muss dann nur ein Unterverzeichnis 'css' und darin die Datei 'default.css' erstellen, in der man die gewünschten Änderungen vornimmt (am Einfachsten wird es wahrscheinlich sein, die original Datei zu Kopieren und dann zu Ändern, um keine Styles zu vergessen).
Um nun das erweiterte Theme zu benutzen, muss man in dem Applikationscode folgende Zeile einfügen:
setTheme("NameDesTheme");
Bemerkung: 'getTheme()' gibt 'null' zurück, wenn das Standard Theme ('default') verwendet wird. Will man zum Standard Theme zurück wechseln, muss man 'setTheme("default")' verwenden und nicht 'setTheme(null)'.
7 Fazit
Das Model-View-Controller-Paradigma ist heute aus größeren Projekten kaum mehr wegzudenken, da die Applikationen eine Komplexität erreichen, die nur mehr im Team in vernünftigen Zeiträumen zu erledigen ist. Um hierbei das Konfliktpotential der einzelnen Teile möglichst gering zu halten, muss man nicht nur die Programmlogik in mehrere nur mittels definierter Schnittstellen kommunizierende Teile auftrennen, sondern auch die eigentliche Logik von der Eingabe und der Ausgabe, sowie diese beide untereinander zu trennen. Wie wir gesehen haben, hat diese Trennung noch weitere Vorteile: etwa die einfachere Wartbarkeit des übersichtlicheren Codes, die nicht (oder nur kaum) vorhandenen Einflüsse auf die anderen beiden Teile bei einer Änderung im dritten Teil oder die Austauschbarkeit der Ein- und Ausgabe um mit der gleichen Programmlogik unterschiedliche Darstellungsarten zu erreichen.
Wir haben auch gesehen, dass es mehrere Arten der Umsetzung der Model-View-Controller-Paradigma im Java-Umfeld gibt. Die Möglichkeiten gehen hier von Servlets über Java-Server-Pages und eXtensible-Server-Pages bis hin zu Frameworks wie Struts und Cocoon und schließlich hierarchischen Model-View-Controller-Frameworks wie Millstone. Während in dieser Reihenfolge die Komplexität der Implementierung größerer Applikationen immer mehr abnimmt wird ein direkten Eingreifen in das optische Ergebnis immer komplizierter. So ist es bei den hierarchischen Model-View-Controller-Frameworks nicht mehr so einfach möglich einem einzelnen Element in HTML mittels eines style-Attributs zum Beispiel eine leicht abweichende Position zuzuordnen, statt dessen muss man eine eigene CSS-Klasse definieren, die bis auf die paar abweichenden Werte der ursprünglichen Klasse entspricht und diese Klasse dann (falls überhaupt möglich) dem Objekt zuweisen. Andererseits benötigt man bei den hierarchischen Frameworks nur Kenntnisse in Java und nicht in HTML und CSS bzw. XML und XSLT. Es ist also wie so oft eine Frage der jeweiligen Anforderungen und Vorlieben zu welcher Umsetzung des Model-View-Controller-Paradigmas man greift.
In Unternehmen kommen noch weitere Punkte hinzu, die sich auf eine Entscheidung pro oder contra einer bestimmten Umsetzung des Model-View-Controller-Paradigmas auswirken. Da ist einerseits der Support, der bei kommerziellen Frameworks meist teurer aber dafür umfassender ist als bei Open-Source-Frameworks (wobei ich hier weniger an Handbücher als viel mehr an Schulungen und Unterstützung bei größeren Implementierungs-Problemen denke).
Andererseits sind kommerzielle Fameworks meist in ihrer Anschaffung teurer und es gibt
normalerweise auch keine Zusicherung für den Preis von Folgeversionen. So kann man etwa bei den Open-Source-Frameworks Struts und Cocoon von der Apache Foundation davon ausgehen, dass auch zukünftige Versionen frei (und gratis) erhältlich sind. Bei kommerziellen Frameworks wie Millstone könnte es aber durchaus geschehen, dass die jeweilige Firma ihr Geschäftsmodell ändert und den Preis für das Framework anhebt, oder es überhaupt nur mehr in Kombination mit Entwicklung oder Support vertreibt. Für die WeLearn-Edition von Millstone geht hiervon aber keine Gefahr aus, da die zugrunde liegende Millstone-Version kostenlos als Open-Source zur Verfügung steht, und dies nur bei einer zukünftigen Folgeversion geändert werden könnte.
In dieser Arbeit wurde zuerst ein grundlegender Überblick über e-Learning und WeLearn, die Lernplattform in deren Rahmen diese Arbeit geschrieben wurde, gegeben. Danach wurde detailliert auf das View-Controller-Paradigma, und auf das hierarchische Model-View-Controller-Framework Millstone, das für den praktischen Teil diese Arbeit die Ausgangsbasis bildete, eingegangen, um schließlich bei der Einführung in die Millstone-WeLearn-Edition zu enden.
Ziel dieser Arbeit war es eine theorethische Einführung für das Model-View-Controller-Paradigma zu geben und schließlich das hierarchische Model-View-Controller-Framework Millstone als Millstone-WeLearn-Edition an die Bedürfnisse von WeLearn anzupassen und um neue Komponenten zu erweitern. Die WeLearn-Edition ist nicht mehr notwendigerweise auf JavaScript angewiesen, bietet jedoch mit JavaScript etwas mehr Komfort. Narürlich ist dieses Framwork nicht nur auf WeLearn im Speziellen oder e-Learning im Allgemeinen beschränkt, sondern kann für jegliche Art von Web-Applikation verwendet werden. Zur leichteren Verwendbarkeit findet sich in dieser Arbeit auch ein Benutzerhandbuch, das die wichtigsten Klassen und Methoden etwas ausführlicher als in der Millstone-API beschreibt, und zusätzlich mit einigen Beispielen sowohl den Einstieg in die Programmierung mit Millstone, als auch die Erweiterung von Millstone um eigene Komponenten erleichtert.