Post on 26-Jan-2023
Bachelorarbeit
Nutzenpotenziale der XPages-Technologie für das Web-Frontend eines
Dokumentenmanagementsystems
Prototypische Implementierung am Beispiel von GCC K-Pool und IBM Lotus
Notes/Domino 8.5
vorgelegt bei
Prof. Dr. Ludwig Nastansky
Wintersemester 2008/2009
vorgelegt von
Nelli Ens
Studentin der Wirtschaftsinformatik
ii
Inhaltsverzeichnis
Abbildungsverzeichnis .......................................................................................................... iii
Abkürzungsverzeichnis ......................................................................................................... iv
1 Einleitung ........................................................................................................................ 1
1.1 Zielsetzung .............................................................................................................. 1
1.2 Aufbau der Arbeit .................................................................................................... 2
2 Technische Grundlagen .................................................................................................. 3
2.1 Dokument ................................................................................................................ 3
2.2 Dokumentenmanagementsysteme ........................................................................... 5
2.3 Moderne Web-Frontends ......................................................................................... 7
2.4 IBM Lotus Notes/Domino ....................................................................................... 9
2.5 XPages als neues Designelement .......................................................................... 12
2.5.1 Funktionale Betrachtung ................................................................................ 12
2.5.2 Technische Betrachtung ................................................................................. 16
3 Darstellung des Konzepts ............................................................................................. 19
3.1 GCC K-Pool als Dokumentenmanagementsystem ................................................ 19
3.1.1 Systemumgebung ........................................................................................... 19
3.1.2 Besonderheiten des Web-Frontends ............................................................... 21
3.2 Anforderungen an die Lösung ............................................................................... 23
3.3 Konzepte zur Umsetzung der Anforderungen ....................................................... 24
4 Prototypische Realisierung ........................................................................................... 31
4.1 Vorstellung des neuen Web-Frontends ................................................................. 31
4.2 Beschreibung der Umsetzung ................................................................................ 33
4.3 Ausblick ................................................................................................................. 37
4.4 Nutzenpotenziale der XPages (Fazit) .................................................................... 38
5 Zusammenfassung ........................................................................................................ 40
6 Literatur ........................................................................................................................ 41
7 Anhang .......................................................................................................................... 44
Eidesstattliche Erklärung ..................................................................................................... 51
iii
Abbildungsverzeichnis
Abbildung 1: Formen von Dokumenten ............................................................................ 4
Abbildung 2: Funktionen der DMS ..................................................................................... 7
Abbildung 3: Beispiel eines Tag-Clouds ............................................................................... 9
Abbildung 4: Zusammenhänge der Elemente in NSF.......................................................... 11
Abbildung 5: Beispiel der Datenbindung in XPages ........................................................... 14
Abbildung 6: Beispiel der Implementierung eines Custom Controls .................................. 15
Abbildung 7: CSS Formatierungen erstellen und exportieren ............................................. 15
Abbildung 8: JSF User Interface .......................................................................................... 17
Abbildung 9: Rendering der JSF Komponente ................................................................... 17
Abbildung 10: Web-Ansicht des K-Pools .......................................................................... 21
Abbildung 11: Ansicht eines Dokuments im Web ............................................................... 22
Abbildung 12: Warnungsmeldung bei "HTML-Conversion" .............................................. 27
Abbildung 13: K-Pool mit XPages ...................................................................................... 31
Abbildung 14: Hinzufügen von Attachment zum Dokument .............................................. 32
Abbildung 15: Darstellung eines XPage-Dokuments .......................................................... 33
Abbildung 16: Ablaufdiagramm zu der View-Navigation.................................................. 36
Abbildung 17: Template für K-Pool Layout ....................................................................... 37
iv
Abkürzungsverzeichnis
ACL
AJAX
CSS
DDE
DMS
DOM
FTP
GCC
HTML
IBM
JSF
JSP
K-Object
K-Pool
MVC
NSF
PIM
RCP
SSL
UNID
URL
WWW
XML
XSP
Access Control List
Asynchronous JavaScript and XML
Cascading Style Sheets
Domino Designer in Eclipse
Dokumentenmanagementsystem
Document Object Model
File Transfer Protocol
Groupware Competence Center der Universität Paderborn
Hypertext Markup Language
International Business Machines
JavaServer Faces
JavaServer Pages
Knowledge Object
Knowledge Pool
Model View Controller
Notes Storage Facility
Personal Information Management
Rich Client Platform
Secure Sockets Layer
Universal ID
Uniform Resource Locator
World Wide Web
Extensible Markup Language
Extensible Server Pages
1 Einleitung
1 Einleitung
1.1 Zielsetzung
Wirtschaft und Verwaltung sind in den letzten Jahren immer komplexer geworden. Die
neuen Kommunikationstechnologien sind heute bereits in beinahe alle Bereiche der Ge-
schäftswelt vorgedrungen, so dass angesichts des starken unternehmerischen Konkurrenz-
kampfes größere Mengen an Informationen bewältigt werden müssen. Eine wesentliche
Rolle spielt insofern eine schnelle und effiziente Verarbeitung dieser Informationsmengen.
Dieses Problem wird durch die erheblichen informationstechnischen Fortschritte und groß-
räumige moderne Datennetze verschärft, da zunehmend mehr Daten produziert werden
(vgl. Gulbins et al., 2004, S. 1 f.). Die herkömmliche, papierbasierte Dokumentenverwal-
tung leidet unter gewissen Einschränkungen. Unter anderem besteht eine beschränkte Ka-
tegorisierungsmöglichkeit darin, beispielsweise einen Kundenbrief nur in einen Ordner
einzusortieren, oder auch in der Weiterleitung dieses Kundenbriefs, die sich meist nur
durch redundantes Kopieren umsetzen lässt. Durch den Einsatz von elektronischen Doku-
mentenmanagementsystemen (DMS) soll das Unternehmen beträchtliche Produktivitäts-
steigerung erzielen (vgl. Kampffmeyer, 1999, S 18).
Die stetige Entwicklung der Technik, der Systeme im Dokumentenmanagement-Bereich
und der Verbreitung des Internets zwingen die Unternehmen, dem Entwicklungstrend zu
folgen, um wettbewerbsfähig zu bleiben. Der Dokumentmanagement-Markt ist jedoch sehr
unübersichtlich und dynamisch, so dass es zusehends schwieriger wird, einen Überblick zu
gewinnen (vgl. Kampffmeyer, 1999, S. 21 f.). Als eine der bekanntesten Plattformen im
Bereich der kollaborativen Anwendungen und im Dokumentenmanagement hat sich IBM
Lotus Notes/Domino etabliert. Die neusten Entwicklungen auf der Plattform sind die soge-
nannten XPages, welche die Möglichkeiten der interaktiven Anwendungsentwicklung im
Web anbieten sollen. Dadurch soll eine große Menge neuer Web-Technologien zur Verfü-
gung stehen, die Einzug in die DMS halten könnten.
Der Schwerpunkt der vorliegenden wissenschaftlichen Arbeit liegt in der Konzeption und
der prototypischen Entwicklung eines neuen Web-Frontends für ein Dokumentenmanage-
mentsystem mit Hilfe der neuen Technologie „XPages“. Die Umsetzung soll exemplarisch
am Groupware Competence Center (GCC) Knowledge-Pool (K-Pool) erfolgen. Das primä-
re Ziel ist, die Möglichkeiten von XPages zu erforschen, zu analysieren und bei der Um-
2 Einleitung
setzung anzuwenden. Die Nutzenpotenziale der XPages für ein DMS sollen in Rahmen
dieser Arbeit betrachtet und die dabei gewonnenen Erkenntnisse dargelegt werden.
1.2 Aufbau der Arbeit
Die Arbeit ist in drei Hauptbereiche gegliedert: Einführung, Konzeption und Darstellung
der Lösung. Die Einführung in die technischen Grundlagen soll dem Leser dieses Werkes
zunächst die zu Grunde liegenden Begriffe näherbringen. Zu diesem Zweck wird zuerst
eine einheitliche Verständnisbasis in Bezug auf die Begriffe Dokument und DMS gebildet.
Danach wird der Begriff Web-Frontend definiert und es werden die aktuellen Tendenzen
im Bereich Web 2.0 in Augenschein genommen. Zum Schluss wird die IBM Lotus No-
tes/Domino Plattform vorgestellt und es werden die neuen Designelemente XPages von der
funktionalen und technischen Seite betrachtet.
Im dritten Kapitel steht die Ausarbeitung eines Konzepts für die prototypische Umsetzung
im Mittelpunkt. Zu Beginn wird die Systemumgebung K-Pool veranschaulicht und die
Anforderungen an die Lösung werden aus den vorher erarbeiteten Grundlagen abgeleitet.
Im Folgenden werden unterschiedliche Methoden und Möglichkeiten der Umsetzung den
definierten Anforderungen gegenübergestellt und analysiert.
Die Vorstellung der Lösung und eine Beschreibung der Besonderheiten der prototypischen
Realisierung werden im vierten Kapitel präsentiert. Im Anschluss an die Vorstellung des
Prototyps werden die Nutzenpotenziale der XPages in einem abschließenden Fazit gewür-
digt. Darüberhinaus wird ein Ausblick auf die zukünftigen Erweiterungsmöglichkeiten des
Prototyps gegeben.
3 Technische Grundlagen
2 Technische Grundlagen
In diesem Kapitel wird zunächst eine gemeinsame Verständnisbasis vermittelt, welche für
die spätere Konzeption und die prototypische Umsetzung wichtig ist, indem die relevanten
Begrifflichkeiten erläutert werden.
2.1 Dokument
Bevor die Dokumentenmanagementsysteme erläutert werden, ist es wichtig, den Begriff
des Dokumentes zu definieren, denn nach Ansicht von Götzer werden die Funktionen eines
DMS im Wesentlichen durch den Art und Zweck von Dokumenten bestimmt (vgl. Götzer
et al., 2004, S. 9).
Ein Dokument dient als ein Informationsträger, dabei ist es gleichgültig, ob es sich um ein
papiergebundenes Schriftgut oder eine Datei handelt, und kann zum Nachweis gewisser
Tatsachen bzw. als ein potenzielles Beweismittel eingesetzt werden (vgl. Götzer et al.,
2004, S. 9).
Nach Gulbins et al. kann ein Dokument aus einer oder mehreren Seiten Information beste-
hen, unabhängig davon, ob es sich um einfachen oder strukturierten Text handelt (vgl.
Gulbins et al., 2004, S. 18). Für die Erklärung der DMS reicht dieses Verständnis nicht aus
und wird durch eine Definition von Bodendorf erweitert, der unter einem Dokument eine
Einheit aus Inhalt, Struktur und Layout versteht. Der Inhalt kann aus den eigentlichen In-
formationen bestehen, deren Abfolge und Aufbau die Struktur des Dokuments widerspie-
geln. Das Layout ist für die visuelle Aufbereitung dieser strukturierten Informationen ver-
antwortlich (vgl. Bodendorf, 2006, S. 69).
Innerhalb eines DMS kommen elektronische Dokumente aus unterschiedlichen Quellen
zum Einsatz. Es handelt sich zum einen um die ursprünglich papierbasierten Dokumente,
die in ein digitales Format umgewandelt wurden (z.B. durch Scannen) und zum anderen
um die vom System selbst erzeugten Objekte (z.B. Textdateien und Tabellen).
Des Weiteren differenzieren Kampffmeyer/Merkel verschiedene Erscheinungsformen von
elektronischen Dokumenten. Entsprechend ihrer Komplexität werden Elementare Doku-
mente, Compound-Dokumente und Container-Dokumente unterschieden. Die ersten kön-
nen aus einem Objekt bestehen und Daten eines Typs (z.B. gescannte Seite) beinhalten,
dagegen können die Compound-Dokumente aus mehreren Objekten zusammengesetzt
werden. Ein Container-Dokument kann aus komplexen Objekten, Verweisinformationen,
Links etc. gebildet werden (vgl. Kampffmeyer/Merkel, 1999, S. 29).
Folgende Abbildung gibt einen Überblick über die Erscheinungsformen der Dokumente.
4 Technische Grundlagen
Abbildung 1: Formen von Dokumenten (Kampffmeyer/Merkel, 1999, S. 29)
Für die Verwaltung von Dokumenten in einem DMS werden unterschiedliche Elemente
und Informationen benötigt. Götzer et al. führen folgende Elemente an: (vgl. Götzer et al.,
2004, S.13 f.).
Eigentliche Dokument: Das Dokument kann, wie oben beschrieben, verschiedene
Informationen enthalten und wird in seinem Format übernommen und gespeichert.
Schlüssel (Key): Für das Auffinden eines Dokumentes in DMS muss dieses identifi-
zierbar sein, was typischerweise durch einen eindeutigen Schlüssel (wie eine Rech-
nungsnummer oder einen künstlichen Schlüssel) gegeben ist.
Metadaten zum Dokument: Neben den tatsächlichen Inhalten sind Metadaten zu
verwalten und für die Informationsauffindung mit einzubeziehen.
Strukturinformationen: Optional kann ein Dokument über Strukturinformationen
im Hinblick auf seinen inneren Aufbau verfügen.
Regeln: Mit den Regeln können die Zugriffsrechte, die Lebensdauer und die ande-
ren Verhaltensweisen für ein Dokument definiert werden.
Gulbins et al. heben vor allem die Forderung von geeigneten Metainformationen für rele-
vante und qualitätsvolle Suchergebnisse in einem DMS hervor. Hierzu können neben dem
Dokumentennamen zusätzliche Suchmerkmale und Attribute wie Autor, Datum, Format,
inhaltliche Informationen, Schutzinformationen zugeordnet werden. Diese Attribute oder
Indexwerte werden in der Regel bei der Aufnahme eines Dokumentes in die DMS erfasst.
Das Dokument kann zu einem späteren Zeitpunkt über seine Attribute bei einer Recherche
gefunden werden. Diesen Vorgang bezeichnen Gulbins et al. als Indizierung bzw. Attribu-
tierung1 (vgl. Gulbins et al., 2004, S. 19).
Außer seinen physischen Eigenschaften bzw. seiner Erscheinungsform und seinem Inhalt
verfügt ein Dokument über einen Lebenszyklus und eine Lebensdauer. Der Lebenszyklus
1 Einen detailierten Überblick über Erfassung, Indizierung und Attributierung geben (Gulbins et al., 2004, S.
372 ff.)
5 Technische Grundlagen
beginnt mit der Erstellung, führt über die Speicherung, Bearbeitung etc. bis hin zur Ver-
nichtung des Dokuments (vgl. Kampffmeyer, 2003, S. 56 f.). Des Weiteren kann ein Do-
kument unterschiedliche Zustände einnehmen wie z.B. „in Bearbeitung“, „im Entwurf“,
„beendet“ (vgl. Götzer et al., 2004, S. 15).
2.2 Dokumentenmanagementsysteme
Das Dokumentenmanagement beinhaltet primär die Verwaltungsfunktionen und Administ-
ration der Dokumente und umfasst alle Prozesse, Abläufe und Verantwortlichkeiten, die
involviert sind. Die zum Einsatz kommenden Werkzeuge wie IT-Anwendungen zur Ver-
waltung und Archivierung der elektronischen Dokumente werden als DMS bezeichnet
(vgl. Götzer et al., 2004, S. 2 ff.).
Bodendorf definiert DMS als Systeme zu strukturierten Erzeugung, Ablage und Verwal-
tung von elektronischen Dokumenten. Ein DMS besteht demnach aus einer Komponente
zur Indizierung der Dokumente, einer elektronischen Ablage sowie Suchmechanismen zum
Wiederauffinden der Dokumente. Einzelne Komponenten können auf unterschiedliche
Systeme (z.B. verschiedene Server) verteilt sein (vgl. Bodendorf, 2006, S. 108 f.). Götzer et
al. weisen darauf hin, dass ein Dokument nur ein einziges Mal gespeichert werden soll,
trotzdem soll es möglich sein, das Dokument jederzeit, sofort, vollständig und aktuell auf-
zufinden. Insofern muss es den Anwender nicht kümmern, wo die Informationen gespei-
chert sind und von welchen Mechanismen sie zur Verfügung gestellt werden (vgl. Götzer
et al., 2004, S. 16).
Ein DMS soll den kompletten Dokumentenlebenszyklus (von der Erstellung bis zur Lö-
schung) abdecken und verwaltet hauptsächlich die Dokumente mit längerer Lebensdauer,
die unterschiedliche Zustände annehmen können. Dies weist auf die Notwendigkeit des
Versionsmanagements, der Verwaltung der Zugriffsreche der und Volltextrecherche hin
(vgl. Gulbins et al, 2004, S. 11). Darüber hinaus soll ein dezentraler Zugriff auf die elekt-
ronischen Dokumente eine gleichzeitige Verwendung der Informationen für mehrere Per-
sonen erlauben und somit die Nutzbarkeit von Dokumenten erhöhen (vgl. Gulbins et al.,
2004, S. 14).
Die obengenannten Funktionen eines DMS können in Anlehnung an Götzer et al. unter
folgenden Oberbegriffen zusammengefasst werden: (vgl. Götzer et al., 2004, S. 17 ff.)
Eingabe (Eingang und Indizieren)
Der Dokumenteneingang befasst sich mit der physischen Übernahme der Doku-
mente in das DMS. Wie im vorherigen Kapitel beschrieben, können die Dokumente
aus unterschiedlichen Quellen übernommen werden.
6 Technische Grundlagen
Die Indizierung der Dokumente stellt einen logischen Teil des Eingabefunktionsbe-
reichs dar und umfasst vor allem das Versehen der Dokumente mit Metadaten,
Schlagwörtern und Attributen. Diese Angaben können automatisiert (vom System,
anhand der vorgegebenen Regeln) oder manuell (durch den Benutzer) erfolgen.
Ablage (Verwaltung und Archivierung)
Die Verwaltung der Dokumente in einem DMS umfasst unter anderem das Versi-
onsmanagement (bei der Weiterbearbeitung der Dokumente) und die Statusverwal-
tung (wenn Zugriffsrechte auf die Dokumente von dessen Status abhängen). Wie
auch papierbasierte Dokumente (z.B. thematisch in Ordnern) abgeheftet und sor-
tiert werden, sollen die elektronischen Dokumente in einem DMS wiederauffindbar
abgelegt und verwaltet werden. Die Sortierung erfolgt anhand der Kategorisierung
der Dokumente durch die Vergabe von weiteren hierarchischen Strukturinformatio-
nen (beispielsweise durch eine Klassifikation nach Art oder Herkunft der Doku-
mente).
Der Funktionsbereich Archivierung widmet sich der Speicherung (z.B. Festplatten-
systemen, Datenbanken) der Dokumente. Ein sicherer und schneller Zugriff muss
gewährleistet werden.
Ausgabe (Recherche und Reproduktion)
Die Recherchefunktion ermöglicht eine gezielte Suche (z.B. Volltextsuche oder
strukturierte Suche anhand der Klassifikation oder der Attribute) nach Informatio-
nen. Ein DMS muss über eine komfortable und intuitive Benutzeroberfläche verfü-
gen, um den Nutzern eine intuitive Suche zu gewährleisten.
Die Reproduktion setzt sich mit der Präsentation der Dokumente auseinander, diese
können beispielsweise dem Benutzer am Bildschirm angezeigt, gedruckt oder wei-
tergeleitet werden. Die webbasierten DMS liefern darüber hinaus Techniken zur
Verlinkung der Dokumente mit anderen Objekten (Bilder, Webseiten, andere Do-
kumente etc.).
Administration
Die Administration umschließt alle Funktionen zum Regeln und Kontrollieren der
Zugriffe innerhalb eines DMS, Schutz von unbefugten Zugriffen und Sicherung der
Daten, Recovery (Wiederherstellen).
Folgende Grafik verdeutlicht die Zusammenhänge der Funktionen eines DMS.
7 Technische Grundlagen
Abbildung 2: Funktionen der DMS (in Anlehnung an Götzer, 2004, S. 16)
2.3 Moderne Web-Frontends
Um den Begriff Web-Frontend zu definieren, sollen zunächst die Begriffe „Web“ und
„Frontend“ eingeführt werden.
Web
Im allgemeinen Sprachgebrauch wird Web mit dem Begriff „ Internet“ oder dem „World
Wide Web“2, kurz WWW genannt, in Zusammenhang gebracht. Avci et al. bezeichnen
Internet als ein weltweites Computernetzwerk, welches für Jedermann einen Zugriff auf
seine Dienste wie E-Mail, WWW oder FTP3 erlaubt (Avci et al., 2003, S. 2). Der Informa-
tionsdienst WWW wird als ein wesentlicher Baustein des Internets bezeichnet, bei dem es
sich um ein Konzept zu Erschließung von Ressourcen im Internet handelt (vgl. Avci et al.,
2003, S. 20).
Meinel/Sack erweitern und vertiefen das Verständnis des WWWs oder einfach des Webs
und beschreiben es als eine Informations- und Datenansammlung von beachtlichem Aus-
maß, auf die mit Hilfe des Internets zugegriffen werden kann. Darüber hinaus soll es sich
um ein „verteiltes Hypermedia-System“ 4 handeln. Die Hypermedia-Dokumente
5, im Web
als Page (Seite) bezeichnet, liegen prinzipiell auf den Rechnern über die ganze Welt ver-
teilt und können über so genannte Hyperlinks (Verweise, Verknüpfungen) miteinander
verbunden werden. Mit Hilfe eines Browsers, der diese Hypermedia-Dokumente interpre-
tieren kann, können sie dem Web-Nutzer dargestellt werden (vgl. Meinel/Sack, 2003,
S. 12 f.).
2 weltweites Datennetz
3 File Transfer Protocol
4 Unterschied zu nicht-verteilten Hypermedia-Systemen siehe (Meinel/Sack, 2003, S. 18 f.)
5 Elektronische, multimediale Dokumente, die neben Text auch Grafiken, Bilder und andere multimediale
Informationsmedien enthalten können. (vgl. Meinel/Sack, 2003, S. 50 )
8 Technische Grundlagen
Frontend
Kampffmeyer liefert zu dem Begriff eine Definition. Frontend ist demnach eine Bezeich-
nung für den Teil einer Anwendung, die dem Benutzer unmittelbar zur Verfügung steht
(vgl. Kampffmeyer, 2003, S. 352). In der Informationstechnik wird darunter eine grafische
Benutzeroberfläche, die dem Benutzer eine Navigation und Bedienung über die Inhalte und
Funktionalitäten des Programms anbietet, verstanden.
Anschließend kann der Begriff „Web-Frontend“ als einen Teil einer Web-Anwendung
definiert werden, der dem Benutzer in Form einer Page über den Browser sichtbar ist und
einen Zugriff auf die Informationen der Hypermedia-Dokumente vermittelt.
Aktuelle Entwicklungstendenzen im Bereich Web 2.0
Die Web-Frontends haben sich im Laufe der Jahre seit der Erfindung des Internets stark
verändert, anfänglich bestanden sie hauptsächlich aus statischen Inhalten, heute sind die
dynamischen, interaktiven Webseiten nicht mehr wegzudenken.
In der neuen Zeit ist ein weiterer Wandel in Web festzustellen - die Trends gehen in Rich-
tung Web 2.0 (vgl. Moussaoui/Zeppenfeld, 2007, S. 15).
Dieser Begriff entstand 2001 bei einer Konferenz zwischen Tim O’Reilly und MediaLive
International6, damit wird ein Wendepunkt des Internets in Richtung neuer Anwendungs-
möglichkeiten bezeichnet. Ein wichtiger Punkt dieser Anschauung ist ein vollständig ande-
res Verständnis von der Rolle des Benutzers und dessen stärkere Einbindung in die Netz-
strukturen - es soll ein „Mitmach-Web“ gestaltet werden (vgl. Maurice, 2007, S. 9 f.).
Die mit Web 2.0 verbundenen Begriffe und Technologien sind unterschiedlicher Art. Unter
anderem sind es Tags (Schlagwörter) und Tagging (Schlagwörter vergeben), damit können
die Informationen einfacher gefunden werden, außerdem bieten diese Tags eine wichtige
Orientierung für andere Benutzer. Die feste Vergabe von Tags wird als Taxonomy (Klassi-
fikation) bezeichnet. Das System, in dem die Benutzer selbst die Tags vergeben und somit
eigene Klassifizierung vornehmen, wird als Folksonomy (Volk und Taxonomy) definiert
(vgl. Maurice, 2007, S. 15 f.). Ein weiterer, damit verbundener Begriff, sind die sogenann-
ten Tag-Clouds (Schlagwort-Wolke), bei denen die wichtigsten oder häufigsten Tags, z.B.
durch eine andere Farbe oder Schriftgröße, hervorgehoben und als Link in einer Wolke
dargestellt werden, siehe die Abbildung (vgl. Maurice, 2007, S. 42).
6 http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html [letzter Zugriff:
19.01.09]
9 Technische Grundlagen
Abbildung 3: Beispiel eines Tag-Clouds
http://www.flickr.com/photos/tags [letzter Zugriff: 21.01.09]
Als technologische Grundlage für viele Web 2.0-Applikationen wird häufig Asynchronous
JavaScript and XML7 (AJAX) verwendet, damit ist eine Kombination von Technologien
gemeint, die eine bessere Benutzerführung für die Anwendungen ermöglicht. Diese Tech-
nik wird ebenfalls mit Web 2.0 in Verbindung gebracht und bietet, Seiteninhalte mit ser-
verseitigen Informationen zu aktualisieren, ohne die Seite komplett neu laden zu müssen
(vgl. Moussaoui/Zeppenfeld, 2007, S. 1 f.).
Die AJAX umfasst solche Technologien wie JavaScript, Cascading Style Sheets(CSS)8 zur
Darstellung von Elementen, Document Object Model (DOM), um Strukturen von Websei-
ten oder Dokumenten zu verändern, XML für den Datenaustausch, und wird plattform-
unabhängig von den Webbrowsern unterstützt, die sich fernerhin JavaScript bedienen. Mit
Hilfe von AJAX kann die sogenannte Typeahead-Funktionalität (Vorschlagsliste) realisiert
werden. In diesem Zusammenhang wird einem Benutzer bei der Eingabe eines Begriffs in
das Suchfeld eine Vorschlagsliste mit passenden Suchbegriffen angezeigt, die mit den
eingegebenen Buchstaben beginnen und automatisch in die Suche übernommen werden
können (vgl. Maurice, 2007, S. 185 ff.).
2.4 IBM Lotus Notes/Domino
IBM Lotus Notes/Domino ist eine weltweit führende Plattform, die besonders im Group-
ware9-Bereich ihre Stärken zeigt. Schon mit der ersten Version im Jahr 1989 wurden leis-
tungsstarke Funktionalitäten angeboten, die heute die Grundlage der meisten Groupware-
Anwendungen bilden (vgl. Ekert, 2006, S. 4).
Bei Lotus Notes/Domino handelt es sich um ein verteiltes System, welches auf den Prinzi-
pien einer Client/Server-Architektur basiert. Lotus Domino stellt die Seite des Servers dar
und ist beispielsweise für die Kommunikation zwischen anderen Clients oder Servern, für
7 Extensible Markup Language
8 Für mehr Informationen zu CSS siehe beispielsweise (Avci et al., 2003, S. 139 ff.)
9 Integrationsplattform für Office-Anwendungen zur Unterstützung der Gruppenzusammenarbeit (vgl.
Kampffmeyer/Merkel, 1999, S. 79)
10 Technische Grundlagen
die Autorisierung und für die Verwaltung von Zugriffsrechten zuständig. Lotus Notes bil-
det die Seite des Clients ab und erlaubt den Anwendern, eine lokale Betreibung und Bedie-
nung der Domino-Applikationen auf ihren Rechnern. Des Weiteren fungiert Lotus Notes
als ein grafischer Personal Information Manager (PIM) mit einem integriertem Webbrow-
ser und kann auch als eigenständige Anwendung betrieben werden (vgl. Donskoj et al.,
2004, S. 31 f.). Ein weiterer Baustein der „Domino-Familie“ ist der Domino-Designer, der
eine integrierte Entwicklungsumgebung für Domino-Applikationen darstellt.
Anwendungsentwicklung mit Domino
Die Domino-Datenbank wird als eine Notes Storage Facility (NSF)-Datei aufgefasst, in der
alle Elemente (von einzelnen Datensätzen bis hin zu Designelementen und Zugriffskont-
rolllisten) einer Notes-Anwendung enthalten sind. Die eigentlichen Daten werden als Do-
kumente gespeichert, diese fungieren als Container (Behälter) für Grafiken, Texte, Objekte
oder multimediale Daten und werden auch Compound Documents (siehe Kapitel 2.1) ge-
nannt (vgl. Donskoj et al., 2004, S. 57 ff.).
Jedes Dokument kann über seine universale Document Unique ID (UNID) innerhalb aller
Repliken (Vielzahl von Domino-Datenbanken)10
einer Datenbank eindeutig identifiziert
werden (vgl. Ekert, 2006, S. 272).
Der Benutzer kann die Dokumente mit Hilfe von Forms (Masken) erstellen, anzeigen oder
verändern. Ekert definiert eine Notes-Form als ein gestaltetes, interaktives Element des
grafischen User Interfaces11
mit vielen programmatischen Fähigkeiten, in dem durch Fel-
der12
Benutzereingaben (wie einfacher Text, Zahlen oder auch komplexe Objekte, die in
speziellem RichText-Feldtyp gespeichert werden) ermöglicht werden (vgl. Ekert, 2006,
S. 43).
Die Anordnung der Felder auf der Form legt eine interne Struktur der Dokumente fest,
somit können die Forms auch als Template (Schablone) für die Dokumente angesehen
werden und erlauben unterschiedliche Sichten auf die gleichen Daten. Es werden zusätzli-
che Elemente wie Tabellen, Grafiken oder Buttons (Schaltflächen) unterstützt und prog-
rammatische Berechnungen auf den Items eines Dokuments können durchgeführt werden.
Neben Forms existieren noch Subforms (Teilmasken), die im Grunde den normalen Forms
ähnlich sind, aber nicht als allein stehendes Element verwendet werden können, sondern
10
Der Replikationsmechanismus von Domino gestattet die Synchronisierung der Anwendungen und Daten
zwischen mehreren Servern oder auch zwischen Server und Client (vgl. Donskoj et al., 2004, S. 24). 11
Benutzerschnittstelle 12
Felder sind Elemente einer Form, die der Eingabe oder Anzeige der Daten dienen und in direkter Verbin-
dung zu einem korrespondiertem Item (Container, in denen die Daten innerhalb des Dokumentes gespeichert
werden) gleichen Namens stehen (vgl. Ekert, 2006, S. 49).
11 Technische Grundlagen
auf anderen Forms eingebettet werden müssen und sich gut für eine Gruppierung wieder-
verwendbarer Elemente eignen (vgl. Donskoj et al., 2004, S. 101 ff.).
Als ein Element für die Selektion, für die optionale Sortierung, für die übersichtliche tabel-
larische Darstellung der Daten von Dokumenten kann ein View (Ansicht) eingesetzt wer-
den. Diese Views können in ihren Spalten Items der ausgewählten Dokumente oder auf
den Berechnungen basierte Werte anzeigen. Views können auch auf einer Form oder
Page13
eingebettet werden und erlauben damit eine schnelle Ansicht der Informationen
(vgl. Ekert, 2006, S. 82).
Folgende Grafik skizziert überblicksartig die Elemente von NSF und verdeutlicht die Zu-
sammenhänge zwischen Dokument, Form und Ansicht.
Abbildung 4: Zusammenhänge der Elemente in NSF
Lotus Notes unterstützt Webanwendungen auf Basis von Domino. Die verfügbaren Forms
und Views können in einem Internetbrowser angezeigt werden, dazu werden diese von
Domino „gerendert“ (browserverständlich übersetzt). Dies kann aber zu einigen Ein-
schränkungen in der Funktionalität und der Darstellung führen, da nicht alle Elemente und
Funktionen des Lotus Notes/Domino im Web vollständig unterstützt werden (vgl. Donskoj
et al., 2004, S. 150 ff.).
Darüber hinaus verfügt der IBM Domino-Designer über zahlreiche weitere Designelemen-
te und Funktionalitäten (Agenten, Aktionen, Vererbungsmechanismen, Unterstützung un-
terschiedlicher Programmiersprachen, Zugriffskontrolllisten [ACL]14
usw.), die in Rahmen
dieser Arbeit nicht näher betrachtet werden15
.
13
Designelement zur Anzeige von Informationen 14
Access Control List 15
Mehr hierzu kann in entsprechender Literatur nachgelesen werden. Siehe z.B. (Donskoj et al., 2004)
12 Technische Grundlagen
Aktuelle Version
Mit der Version 8.0 wurde Lotus Notes auf der Grundlage von Eclipse Rich Client-
Plattform (RCP) neu gestaltet.
Bei der aktuellen16
Version Lotus Notes 8.5, die als technische Grundlage für die Entwick-
lung des Prototypen dienen soll, basiert auch der Domino-Designer auf dem Eclipse Open-
Source Framework (vgl. IBM Corporation, 2008, S. 8).
Der neue Domino-Designer auf Eclipse (DDE) stellt einige Erweiterungen und Verbesse-
rungen für die Anwendungsentwicklung wie neue Designelemente, eine neue Benutzer-
oberfläche des Domino-Designers, die sich einer Eclipse-Oberfläche ähnelt und sich durch
zahlreiche Plug-ins erweitern lässt, bereit.
Besonders hervorzuheben sind folgende Punkte: (vgl. IBM Corporation, 2008, S. 8)
- Erweiterbare Script-Editoren und Debugger17
Framework,
- Integrierte Editoren für CSS, XML und HTML18
,
- XPages und Custom Controls,
- Serverseitige JavaScript-Libraries (Bibliotheken),
- Themes
2.5 XPages als neues Designelement
Wie in dem vorherigen Kapitel erwähnt, handelt es sich bei XPages um ein neues Designe-
lement der aktuellen Lotus Notes/Domino 8.5 Beta Version. Die XPages sollen die Gren-
zen der Webprogrammierung bei Domino durch den Einsatz von fortschrittlichen Techni-
ken brechen und neue Perspektiven für eine dynamische Gestaltung von modernen webba-
sierten Domino-Applikationen eröffnen. Dieses Kapitel liefert einen Überblick über die
wichtigsten Funktionalitäten und die Architektur der XPages und der dazugehörigen Kom-
ponente liefern.
2.5.1 Funktionale Betrachtung
Im Vergleich zu ihren namensverwandten Pages, die in Kapitel 2.4 erwähnt wurden, tragen
die XPages einen dynamischen Charakter und können eher mit einer Form verglichen wer-
den.
Binsack/Gollmick geben einen Überblick über die breite Palette an neuen Elementen wie
Buttons, Links, Tabellen, Felder und andere Controls (Unterelement der XPages). Die
meisten dieser Elemente sind bereits aus früheren Versionen bekannt, neu ist die Bedie-
16
Stand 08.01.09 17
Werkzeug zum Auffinden und Beheben von Fehlern im Programm. 18
Hypertext Markup Language
13 Technische Grundlagen
nung, welche per „Drag and Drop“ realisiert werden kann. Des Weiteren lassen sich
beinahe alle Controls und ihre Parameter dynamisch berechnen, zu diesem Zweck kommt
JavaScript als Programmiersprache zum Einsatz, es ist aber weiterhin möglich, die aus der
proprietären Domino-Entwicklung bekannten @-Functions (vordefinierte Funktionen) ein-
zusetzen, was die Entwicklungszeit verringert. JavaScript kann bei XPages sowohl client-
seitig als auch serverseitig dynamisch während der Laufzeit oder während des Ladens der
XPage ausgeführt werden. Erweiterbare Script-Bibliotheken, Simple Actions (vorprog-
rammierte einfache Aktionen wie das Löschen oder Sichern eines Dokuments, das Öffnen
einer Seite) stehen zur Verfügung. Selbst klassische Elemente wie der RichText-Feldtyp
profitieren von den neuen Optionen, so ist es möglich, dieses RichText-Feld im Browser
mittels JavaScript-Editor zu ändern (vgl. Binsack/Gollmick, 2008).
Pollak weist insbesondere auf die neuen Möglichkeiten der Datenbindung in XPages hin.
Jedes Control-Element kann mit einer oder mehreren Datenquellen (wie z.B. View oder
Dokument) verbunden werden (vgl. Pollak, 2008, S. 2).
Den XPages stehen mehrere Möglichkeiten verschiedene Datenquellen flexibel (direkt
oder dynamisch) zu binden19
bereit, z.B.:
- Ein View Control erlaubt einen Zugriff auf die Daten der Domino Views und kann
direkt auf der XPage als eine Tabelle mit den Daten dargestellt werden.
- Ein Repeat (Wiederholung) Control kann Daten oder andere Controls flexibel an-
zeigen und wiederholen.
- Mit Data Table lassen sich die Daten benutzerdefiniert selektieren und in Spalten
anzeigen.
- Felder auf der XPages lassen sich direkt mit den Feldern oder Items einer Form
binden, dies dient auch der späteren Anzeige der Inhalte des Dokuments.
- Ein direkter Zugriff auf die Dokumente unterschiedlicher NSF ist ebenso möglich.
Binsack/Gollmick vergleichen diese Funktionalität der XPages mit Composite Applicati-
ons, wo es möglich ist, verschiedene Bereiche einer Page aus unterschiedlichen Quellen
(Components) miteinander zu verknüpfen. So lassen sich beispielsweise die Hauptdoku-
mente gleichzeitig mit ihren Anhängen abbilden und bearbeiten, wobei die Aktualisierung
oder Speicherung aller wiedergegebenen Dokumente „mit nur einem Klick“ als interne
Funktionalität von XPages realisierbar ist (vgl. Binsack/Gollmick, 2008).
19
Mehr zu Datenbindung siehe (Dan O’Connor, 2008)
14 Technische Grundlagen
Wie oben bereits erwähnt, können mehrere Dokumente oder Views auf einer XPage ange-
zeigt werden. Da bei den XPages die Daten vom Design (Darstellung) getrennt werden
(siehe technische Betrachtung der XPages), bleiben diese Daten an ihren ursprünglichen
Stellen und müssen nicht kopiert und vervielfältigt werden (vgl Pollak, 2008, S.3).
Die folgende Grafik zeigt die Zusammenhänge zwischen XPages und ihren Datenquellen.
Abbildung 5: Beispiel der Datenbindung in XPages (in Anlehnung an IBM Corporation, 2009)
Wie in der Grafik abgebildet, können die XPages die, sogenannten Custom (benutzerdefi-
nierte) Controls integrieren. Bei ihnen handelt es sich um ein weiteres, neues Designele-
ment innerhalb der DDE, welches als eine Teilkomponente der XPages, ähnlich wie die
Subforms (siehe Kapitel 2.4), auf einer oder mehreren XPages integriert werden kann. Ein
Custom Control kann seinerseits selber aus einzelnen Elementen und Controls bestehen,
welche als einzelne Objekte gespeichert und auf der Custom Controls Palette der Entwick-
lungsumgebung organisiert werden können (siehe dazu die unten stehende Abbildung).
Dort lassen sich annähernd alle Einstellungen dynamisch parametrisieren. Jede XPage er-
hält die Änderungen des implementierten Custom Controls automatisch, somit eignen sie
sich besonders gut für alle wiederverwendbaren Bereiche wie beispielsweise Logos oder
Dokumentenköpfe. Zusätzlich zu den Custom Controls können Editable Areas eingesetzt
werden, sie eröffnen die Möglichkeit, erst nach der Implementierung des Custom Controls
auf der XPage festzulegen, welche Controls oder Datenquellen verwendet werden sollen.
Damit können die Custom Controls noch einen Schritt weit flexibler eingesetzt werden
(vgl. IBM Corporation, 2009).
15 Technische Grundlagen
Abbildung 6: Beispiel der Implementierung eines Custom Controls
Das Aussehen von XPages kann durch den Einsatz von klassischen Gestaltungselementen
wie CSS-Bibliotheken, Grafiken, partialem oder vollem Aktualisieren der Page mit Hilfe
von AJAX-Technologien (siehe Kapitel 2.3) oder unter Verwendung der Web Controls wie
Tabbed Panel (Register Tabelle) flexibel gestaltet werden. Diverse integrierte Editoren20
,
die eine Bearbeitung der (XSP, CSS, XML, HTML) direkt in DDE erlauben, sind vorhan-
den und vereinfachen die Entwicklung der Applikationen.
CSS-Klassen können zu einem XPage und zu einzelnen Controls referenziert werden. Wie
in der folgenden Grafik zu sehen ist, lassen sich viele der CSS-Eigenschaften direkt in
den Einstellungen der Controls erzeugen, diese können auch in eine externe CSS-Datei
exportiert werden.
Abbildung 7: CSS Formatierungen erstellen und exportieren
In Kombination mit dem JavaScript Framework Dojo21
soll es möglich sein, moderne Web
2.0-Anwendungen mit den Vorteilen einer Notes-Anwendung zu entwickeln. Dieses
Werkzeug ist als eine clientseitige JavaScript Library integriert und kann beispielsweise
für Typeahead (Eingabevorschlag) innerhalb eines Eingabefelders oder einer Anzeige ei-
nes Date-Pickers (Datumsauswahl-Komponente) eingesetzt werden. In dieser Version ba-
siert auch die Anzeige des RichText-Feldes im Web auf Dojo und kann durch unterschied-
liche Optionen definiert werden. Diese Optionen lassen das RichText-Feld unterschiedlich
vom Browser interpretieren und darstellen wie die Anzeige als Java Applet, als JavaScript
Control oder als HTML (vgl. IBM Corporation, 2009).
20
Mehr zu Editoren siehe z.B. (Kulkarni, 2008) oder (IBM Corporation, 2009) 21
Mehr zu Dojo siehe http://dojotoolkit.org [letzter Zugriff: 15.12.08]
16 Technische Grundlagen
Nach Binsack/Gollmick geben die neuen Designelemente „Themes“ besonders flexible die
Gelegenheit der Ausgabegestaltung. Diese können das Rendern der Elemente zur Laufzeit
beeinflussen, XML- oder CSS-Eigenschaften der XPage kontrollieren und somit das Aus-
sehen und die Handhabung der Applikation festlegen. Eine benutzerabhängige Lokalisie-
rung22
für die Domino-Applikationen kann mit Hilfe von Themes umgesetzt werden. Es
können mehrere Sprachversionen der Seite mit nur einer XPage angeboten werden (vgl.
Binsack/Gollmick, 2008).
Zahlreiche Möglichkeiten, die Daten und Benutzereingaben server-oder clientseitig zu va-
lidieren sowie eine flexible Fehlerbehandlung23
mittels Error Controls, die eine benutzer-
definierte Fehlermeldung anzeigen können, stehen den XPages ebenfalls zu Verfügung
(vgl. IBM Corporation, 2009).
2.5.2 Technische Betrachtung
Technisch gesehen sind die XPages eine Erweiterung der Java-Server-Faces (JSF)-
Technologie. Zunächst sollen die Grundlagen der JSF behandelt werden, um das Verständ-
nis der technischen Seite der XPages zu vereinfachen.
JSF-Technologie
JSF wird als ein serverseitiges Framework für die Entwicklung von dynamischen, Benut-
zeroberflächen beschrieben, die auf Java-Technologie basieren. Zentrale Elemente der JSF
sind die standardisierten und wiederwendbaren User-Interface-Komponenten (wie Valida-
toren, Datenkonvertierung und Eventmechanismen), mit deren Hilfe die Webanwen-
dungen schneller und effizienter erstellt werden können. Des Weiteren gehören benutzer-
definierte Bibliotheken der JavaServer Pages (JSP) zu den Hauptkomponenten der JSF-
Technologie (vgl. Sun Microsystems, 2008, S.285).
Die JSP-Technologie dient im Wesentlichen der Entwicklung von webbasierten, platt-
formunabhängigen Applikationen (Anzeigen der User-Interface Komponente und Definie-
ren der serverseitigen Objekte). Nach Rockwell liegt die Stärke der JSP in ihrer einfachen
Weise, dynamische HTML-Seiten für den Browser zu produzieren (vgl. Rockwell, 2000,
S. 197).
Folgende Abbildung zeigt das „myUI“ JSF User-Interface, welches sich auf dem Server
befindet und dem Browser gerendert (übersetzt) wird. Die JSP-Seite „myform.jsp“ stellt
die User-Interface-Komponente des JSF dar.
22
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/UsingLocalizationOptions.htm [letzter Zugriff: 15.12.08] 23
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/error-management-in-xpages.htm [letzter Zugriff: 15.12.08]
17 Technische Grundlagen
Abbildung 8: JSF User Interface (Sun Microsystems, 2008, S. 286)
Die JSF-Technologie definiert eine Trennung zwischen der Anwendungslogik und der Prä-
sentation und ist konzeptionell an das Model-View-Controller (MVC)-Architekturmuster
angelehnt, was nach Wahli et al. einen großen Vorteil beinhaltet. In der Anwendung wer-
den die Daten (Model), die Darstellung (View) und die Steuerungskomponenten (Control-
ler) voneinander getrennt. JSF ist hauptsächlich für die Darstellung zuständig und wird mit
Hilfe von JSP realisiert (vgl. Wahli et al., 2004, S. 5 ff.). Zusätzlich wird ein komponenten-
basierter Ansatz verfolgt, bei ihm lassen sich die Benutzeroberflächen nach dem „Baukas-
tenprinzip“ zusammenstellen und mit Eventmechanismen und Validatoren ergänzen (vgl.
Bosch, 2004 S. 307 f.).
XPages
Wie oben bereits beschrieben, ist Xpage ein Designelement, welches zum Darstellen (ren-
dern) der Webseiten genutzt wird, was aktuell mit Hilfe von JSF Render-Kits realisiert
wird. Folgende Abbildung veranschaulicht den Rendering-Prozess.
Abbildung 9: Rendering der JSF Komponente (in Anlehnung an IBM Corporation, 2009)
Lenz nennt einige wichtige Punkte, in denen die Xpages die JSF-Technologie vereinfachen
sollen. Zum einem ist es die Unabhängigkeit von JSP-Servlet24
, da ein XPage Servlet-
Adapter direkt in die Web Engine integriert ist, zum anderen die Unterstützung der
Scriptsprachen wie JavaScript, XPath (Sprache für die Datenbindung) und eine mögliche
Erweiterung durch unterschiedliche Datenquellen, AJAX und XML-Support (vgl. Lenz,
2008, S. 57).
24
Bei Servlets handelt es sich um Java-Programme, die auf dem Webserver laufen und auf Anfragen an den
Server reagieren (vgl. Avci, 2003, S. 530).
18 Technische Grundlagen
Nach der JSF-Architektur und in Anlehnung an das MVC-Modell sind auch bei den XPa-
ges die Daten und Design (Darstellung) getrennt, d.h. die Daten werden nicht mit XPage
gespeichert, sondern verlinken auf die Datenquellen, siehe dazu die Abbildung Nr. 5 (vgl.
IBM Corporation, 2009).
Die XPages werden als Teil der Domino HTTP Server installiert und sind innerhalb der
Web Engine voll integriert, durch die erweiterte URL25
-Syntax, der Form
„http://myserver/mydb.nsf/mypage.xsp“, lassen sie sich in dem Webbrowser aufrufen. Die
XPages werden direkt in einem NSF als XSP-Dateien, was für „eXtensible Server Pages“
steht, in erweiterbarem XML-Dateiformat auf der lokalen Arbeitsstation gespeichert (vgl.
IBM Corporation, 2009).
25
Uniform Resource Locator
19 Darstellung des Konzepts
3 Darstellung des Konzepts
Das Ziel dieses Kapitels ist die Ausarbeitung eines Konzepts zu Implementierung des
Web-Frontends für den K-Pool mit Hilfe von XPages. Zunächst wird die Systemumgebung
vorgestellt, auf der die Umsetzung erfolgen soll. Auf der Basis der im Vorfeld erarbeiteten
Grundlagen wird ein Anforderungskatalog erstellt und das Konzept zur Implementierung
dieser Anforderungen erarbeitet.
3.1 GCC K-Pool als Dokumentenmanagementsystem
3.1.1 Systemumgebung
GCC K-Pool ist eine vielseitige Applikation, die auf der Basis von IBM Lotus Notes/ Do-
mino vor mehreren Jahren vom Groupware Competence Center an der Universität Pader-
born entwickelt wurde. Sie wurde im Laufe der Jahre permanent eingesetzt und stetig er-
weitert. K-Pool stellt eine integrierte und offene Plattform für das Dokumentenmanage-
ment dar und wird zur Sammlung und Verteilung von Informationen genutzt. Gleichzeitig
ist es eine kollaborative Anwendung, die die Kommunikation, Kooperation, Verarbeitung
von Geschäftsprozessen für die Benutzer im Intranet bis hin zum Internet unterstützt. Dar-
über hinaus werden zusätzliche Module angeboten, die der visuellen Unterstützung des
Workflow-, Prozess- und Wissensmanagements dienen (vgl. Hesse, 2006).
Die content-orientierte Vorgehensweise (Trennung der Daten von der Darstellung) von K-
Pool erlaubt eine flexible Anpassung des Layouts und der Funktionen, was eine Mehrfach-
verwendung des Produkts auszeichnet.
Eingabe (Eingang und Indizierung)
Die Übernahme der Dokumente in K-Pool erfolgt aktuell nur über den Lotus Notes
Client, was eine Einschränkung in der Nutzung des DMS impliziert. Die Inhalte
werden in sogenannten Container-Dokumenten (siehe Kapitel 2.1) verwaltet. Sie
können Daten verschiedener Datentypen wie z.B. Text, Verknüpfungen, Tabellen,
Bilder, Anhänge und andere multimediale Objekte sowie die Meta-Daten (wie bei-
spielsweise Titel, Keywords [Schlüsselwörter]) beinhalten, die nähere Informationen
zu dem Objekt bereitstellen. Die Indizierung und die Sichtbarkeitseinstellungen für
die Inhalte können von dem Benutzer vorgenommen werden. Zudem stehen dem Au-
tor viele zusätzliche Einstellmöglichkeiten zur Verfügung wie beispielsweise unter-
schiedliche Header-Varianten, die nach Art des Dokuments gewählt werden können
(z.B. mit Metadaten für Literaturangaben), oder zuvor angefertigte Vorlagen für die
Dokumente, die nachgeladen und eingesetzt werden können.
20 Darstellung des Konzepts
Ablage (Verwaltung und Archivierung)
Eine Weiterverarbeitung der Dokumente ist ebenfalls nur im Client möglich und ist
als eine weitere Nutzeneinschränkung aufzufassen. Das Versionsmanagement (Histo-
ry-Verwaltung) der Dokumente wird unterstützt. Die mehrfache Kategorisierung der
Dokumente über entsprechende Attribute wie Themes, Keywords, Meta Structures
erlauben eine strukturierte Ablage der Dokumente im System über mehrere Ebenen
und ihre Visualisierung in verschiedenen Views, was dem Benutzer die Suche nach
Informationen flexibler gestalten lässt. Für angemeldete Benutzer besteht sowohl im
Client als auch im Web die Gelegenheit einer Kommentierung der Dokumente. Im
Rahmen dieser Funktion kann der Autor wählen, ob die Kommentare im Web sich-
tbar sein sollen oder nicht. Die Container-Dokumente werden nur einmal in einer
zentralen Datenablage im K-Pool gespeichert und archiviert. Die mehrstufigen Si-
cherheitsmechanismen des Lotus Notes/Domino gewährleisten einen sicheren Zu-
griff auf die Daten.
Ausgabe (Recherche und Reproduktion)
Es werden unterschiedliche Recherchemechanismen unterstützt. Die Navigation er-
folgt über die Views, die unterschiedliche Ansichten auf die Strukturen und Hierar-
chien der Dokumente sowohl im Client als auch im Internet bieten. Überdies steht
eine Volltextsuche zur Verfügung.
Zum Zwecke der Reproduktion der Dokumente existieren zwei Frontends für den K-
Pool, zum einen für die Arbeit im Lotus Notes Client, zum anderem ein Web-
Frontend für den Zugriff über Browser.
Administration
Der Zugriff auf die Inhalte kann, wie bereits erwähnt, entweder durch den Lotus No-
tes Client oder über einen beliebigen Internet-Browser erfolgen, wobei der Lotus No-
tes Client eine Authentifizierung des Benutzers erfordert und der Zugriff auf den
Web Client auch anonym erfolgen kann. Die Zugriffsregelung wird von den entspre-
chenden Lotus Notes/Domino-Sicherheitsmechanismen und dem Rollenkonzept in
der ACL gesteuert. Anonyme Benutzer verfügen lediglich über die Möglichkeit, In-
halte im Web zu lesen und zu recherchieren, dagegen steht einem angemeldeten Nut-
zer die Möglichkeit bereit, Kommentare zu den Dokumenten zu verfassen und in
Abhängigkeit von ihren Rechten im System auf die Informationen zuzugreifen.
21 Darstellung des Konzepts
3.1.2 Besonderheiten des Web-Frontends
Da im Rahmen dieser Arbeit der Schwerpunkt in dem Bereich des Web-Frontends liegt,
wird die Einführung auf die Beschreibung der Funktionalitäten desselben beschränkt.
Die Navigation und Recherche können, wie im Vorkapitel beschrieben, durch verschiedene
Views erfolgen, die die Dokumente anhand ihrer Meta-Daten auf unterschiedliche Weise
kombinieren. Die Navigation über Themes, die einen Pfad bzw. die hierarchische Position
des Dokuments im System darstellen sollen, ermöglicht dem Benutzer, die Dokumente
über ihre Pfade zu finden. Ein Dokument kann ebenfalls durch seine Keywords (Schlag-
wörter) gefunden werden, die die Dokumente näher beschrieben. Zu diesem Zweck werden
die gesuchten Keywords über die jeweiligen Klassen aufgerufen, zu denen die Begriffe
zusammengefasst werden. Zusätzlich ist eine Navigation über die Meta Structures eines
Dokuments vorhanden, die ähnlich wie bei Themes und Keywords eine Suche der Doku-
mente anhand ihrer Kategorisierung nach Meta-Strukturen bzw. nach der Art des Doku-
ments anbietet.
Abbildung 10: Web-Ansicht des K-Pools
http://gcc.upb.de/www/WI/WI2/wi2_lit.nsf/KPoolPage?OpenForm&view=KPoolThemes&category=ACTIVITY%20MANAGER
[letzter Zugriff: 15.12.08]
Als eine weitere Möglichkeit der Recherche ist die Volltextsuche anzusehen, bei der sämt-
liche Dokumente und alle eventuell angehängte Informationen nach einem Begriff durch-
sucht werden können. Die entsprechenden Suchergebnisse werden dann in einer geordne-
View-Navigation
Navigation über Kategorien
Volltextsuche
Anzeige von Doc-Header
22 Darstellung des Konzepts
ten Liste visualisiert. Allerdings ist das Suchformular nicht in die Seite integriert und die
auswählbaren Funktionen sind nicht beschrieben.
Der Suchbereich (View-Navigation) dient zum einen der direkten Suche nach Kategorien
innerhalb der Ansichten und zum anderen der Anzeige eines Pfades, der dem Benutzer
zeigt, an welchem Punkt der Struktur er sich gegenwärtig befindet. Außerdem ist eine ein-
fache „Rücknavigation“ zur übergeordneten Kategorie verfügbar. Darüber hinaus ist eine
alphabetische Sortierleiste (View-Exploration) vorhanden, die abhängig von dem ausge-
wählten View einen Zugriff auf alle möglichen Schlagwörter und Kategorien der Doku-
mente bietet.
Die Dokumente werden im Browser angezeigt, wobei die Präsentationsart (mit oder ohne
Dokumenten-Header) von der Auswahl des Benutzers abhängig ist. In dem Dokumenten-
Header werden die Meta-Daten bereitgestellt, die gleichzeitig der Verlinkung auf entspre-
chende Kategorien dienen. Der eigentliche Inhalt wird in einem RichText-Feld wiederge-
geben und kann unterschiedliche multimediale Objekte enthalten. Die zugehörigen Kom-
mentare können ebenfalls in dem Dokument vorgestellt werden. Außerdem können, wie
oben beschrieben, die angemeldeten Benutzer eigene Kommentare zu dem Dokument ei-
narbeiten. Die Anzeige der Kommentare erfolgt in einer separaten Seite, was im Hinblick
auf die Benutzerfreundlichkeit suboptimal erscheint.
Das Layout des Web-Frontends kann benutzerdefiniert gestaltet werden, die Steuerung des
Aussehens wie z.B. der angezeigten Logos, Links, Farben, Schriftarten und -größen ge-
schieht dynamisch anhand der sogenannten Web-Settings, die in dem Administrationsbe-
reich des K-Pools für die aktuelle Anwendung festgelegt werden können.
Abbildung 11: Ansicht eines Dokuments im Web
http://gcc.upb.de/www/WI/WI2/wi2_lit.nsf/KPoolThemes/6C34D9C613D61673C125748100415110?OpenDocument
[letzter Zugriff: 25.01.2009]
Metadaten
Kommentare Inhalt
23 Darstellung des Konzepts
3.2 Anforderungen an die Lösung
Unter Zuhilfenahme eines thematischen Rückgriffs auf die Funktionsbereiche eines DMS
einerseits (vgl. Kapitel 2.2) sowie andererseits auf die Entwicklungstendenzen des moder-
nen Web-Frontends rückblickend (vgl. Kap. 2.3) können die Anforderungen an die Ent-
wicklung des Web-Frontends für den GCC K-Pool exakt definiert werden. Sie sollen als
Grundlage für die Konzipierung und Umsetzung des Prototypen fungieren.
Als Basis für die Anforderungen an das neue Web-Frontend des K-Pools sollen die Eintei-
lung der Funktionsbereiche nach Götzer et al. (vgl. Kapitel 2.2) und die in dem vorherigen
Kapitel beschriebenen Funktionen des K-Pool dienen.
Eingabe (Eingang und Indizierung)
Da die physische Übernahme der Dokumente zurzeit nur im Client vonstatten ge-
hen kann, besteht die Erfordernis, sie um die Möglichkeit der Erstellung im Web zu
erweitern.
Die Inhalte sollten weiterhin in Container-Dokumenten verwaltet werden. Die Indi-
zierung der Dokumente muss alle Metadaten umfassen, die einem Dokument im
Client vergeben werden dürfen. Die Zuteilung der Keywords (Tagging) sollte, wie
es das moderne Web 2.0 vorsieht, von dem Benutzer vorgenommen werden dürfen.
Ablage (Verwaltung und Archivierung).
Da nach Gulbins et al. ein DMS den kompletten Lebenszyklus eines Dokuments
widerspiegeln muss (vgl. Gulbins et al, 2004, S. 11), ist es nahezu unverzichtbar,
dass auch die Weblösung die Gelegenheit offeriert, die Dokumente zu bearbeiten,
weiterzuleiten oder zu entfernen. Um die strukturierte Ablage weiterhin zu gewähr-
leisten, besteht die Notwendigkeit, die Funktionalitäten der Kategorisierung voll-
ständig zu erhalten. Die Option der Kommentierung sollte den angemeldeten Be-
nutzern auch künftig zugänglich sein.
Es ist erforderlich, die Speicherung der Container-Dokumente zentral in der Daten-
ablage des K-Pools vornehmen zu können.
Ausgabe (Recherche und Reproduktion)
Es bietet sich an, die im vorherigen Kapitel vorgestellten Recherchemechanismen
(strukturierte Suche und Volltextsuche) sowie die Navigation umzusetzen. Die
Volltextsuche kann idealerweise in die Hauptseite integriert und die Gestaltung der
Ergebnisliste verbessert werden.
Wie in Kapitel 2.3 erwähnt, ist es sinnvoll, dem Benutzer mit Tag-Clouds und
Typeahead bei der Suche nach Informationen Beistand zu leisten.
24 Darstellung des Konzepts
Die Reproduktion der Inhalte sollte weiterhin sowohl im Client als auch im Web
erfolgen. Die benutzerdefinierte Darstellung des K-Pools durch Web-Settings sollte
nach Möglichkeit berücksichtigt werden.
Administration
Die Konsistenz der Daten muss gesichert werden, so dass keine Informationen
beim Speichern, Bearbeiten und Übertragen verfälscht werden oder sogar verloren
gehen. Aus diesem Grund sollten die Zugriffsregelung und das Rollenkonzept be-
rücksichtigt werden.
3.3 Konzepte zur Umsetzung der Anforderungen
Nachdem die Anforderungen an die Lösung vergegenwärtigt wurden, wird in diesem Kapi-
tel auf der Basis der erarbeiteten Grundlagen ein Konzept zur Realisierung dieser Anforde-
rungen mit Hilfe von XPages (vgl. Kap. 2.5) entworfen. Das primäre Ziel ist, die unter-
schiedlichen Möglichkeiten der Umsetzung vorzustellen und zu diskutieren.
Eingabe (Eingang und Indizierung)
Wie in Kapitel 2.5 beschrieben, bieten die XPages wie auch die klassischen Lotus Notes
Forms dem Benutzer die Chance, die Daten einzugeben und als ein Dokument abzuspei-
chern, was durch eine Verknüpfung der XPage mit der Form realisiert wird.
Metadaten für die Knowledge-Objects (K-Object)
Bei den Metadaten ist zu beachten, dass einige Funktionalitäten wie z.B. die Kategorisie-
rung des neuen Dokuments mit Themes, Keywords und Meta Structures oder das Importie-
ren/Exportieren der Thumbnails in der Form durch LotusScript-Funktionen26
realisiert
wurden. Sie können in XPages nicht eingesetzt werden und müssten aus diesem Grund in
JavaScript neu entwickelt werden. Zur Vereinfachung der Kategorisierung für den Proto-
typ bestehen folgende Optionen:
- Auswahl aus vorhandenen Werten (durch ein Lookup auf die Einträge der Views),
- Eingabe der Tags durch Benutzer, im Sinne der Folksonomy.
Die zweite Möglichkeit integriert den Benutzer im größeren Umfang und lässt ihn die Be-
griffe vergeben. Jedoch kann diese Vorgehensweise dazu führen, dass viele ähnliche Kate-
gorien entstehen, die sich eventuell nur durch die Schreibweise unterscheiden. Die erste
Alternative erhält die vorgegebene Ordnung, jedoch werden die Auswahllisten unter Um-
ständen sehr lang und eine Auswahl wird dadurch nur schwer möglich sein.
26
eine Übersicht der Funktionen befindet sich im Anhang
25 Darstellung des Konzepts
Für das Importieren bzw. Exportieren der Thumbnails bieten sich FileUpload und File-
Download Controls an, welche dem Benutzer das Hinzufügen und Herunterladen von Da-
teien erlauben.
Dokument mit Inhalt füllen
Des Weiteren sollte der Benutzer über die Möglichkeit verfügen, dem Dokument multime-
diale Objekte wie formatierten Text, Bilder, Tabellen, Attachments (Anhänge) hinzufügen.
Der RichText-Editor bei XPages stellt die Funktionalitäten bereit, um den eingegebenen
Text benutzerdefiniert zu formatieren sowie Bilder oder andere Objekte anzuzeigen, je-
doch bietet er nicht so viele Möglichkeiten wie das RichText-Feld in Lotus Notes, welches
darüber hinaus das Erstellen von Tabellen, Hinzufügen von Dateien und Notes-Elementen,
wie z.B. eine View, ermöglicht. Die vorhandenen Lösungsoptionen sind:
- Neben dem RichText-Editor könnte ein FileUpload Control angeboten werden.
- Eine Markierung kann vergeben werden, dass es sich um ein weberstelltes Dokument
handelt und es noch im Lotus Notes Client überarbeitet werden muss, um beispiels-
weise mit spezifischen Notes-Elementen ergänzt zu werden.
a) Markierung vom Benutzer setzen lassen (z.B. durch ein Auswahlfeld),
b) programmatisches Setzen einer Variablen für alle Web-Dokumente.
Die Umsetzung hängt im Wesentlichen von den persönlichen Bedürfnissen der Benutzer
und der Notwendigkeit der Verwendung von Notes-spezifischen Elementen ab. Beide
Möglichkeiten können auch parallel eingesetzt werden.
Dokument speichern
Die Speicherung kann mittels einer vordefinierten Simple Action durchgeführt werden
oder benutzerdefiniert programmiert werden, um z.B. eine Meldung über den Status der
Speicherung aufzurufen oder zusätzliche Item-Werte zu berechnen und zu setzen. Die bei-
den Möglichkeiten können auch nebeneinander verwendet werden, so dass die eigentliche
Speicherung mittels Simple Action realisiert wird und die spezifischen Berechnungen und
Serverabfragen in eine eigene Action ausgelagert werden.
Kontrolle der Benutzereingaben könnte serverseitig oder clientseitig erfolgen
- Die serverseitige Validierung hat den Vorteil, dass sie in jedem Fall sicherer ist, je-
doch wird dadurch der Server belastet.
- Bei der clientseitigen Validierung werden die Potenziale des Browsers genutzt, jedoch
treten mehr Risiken auf, dass die Validierung nicht erfolgt und der Server unter Um-
ständen inkorrekte Daten erhält.
26 Darstellung des Konzepts
Die Entscheidung, welches Verfahren gewählt wird, hängt im Wesentlichen von der Ab-
wägung zwischen Sicherheit und Serverauslastung ab, wobei die sichere Variante vorge-
zogen werden sollte. Um ein Kompromiss zwischen der Serverbelastung und Sicherheit zu
schließen, können die beiden Varianten miteinander kombiniert werden, so dass die stan-
dardmäßigen Prüfungen dem Client des Benutzers überlassen werden und die kritischen
Prüfungen am Server stattfinden.
Um die Benutzereingaben zu validieren, bieten die XPages folgende Varianten:
- Vorhandene vordefinierte Validatoren der Controls nutzen
- Benutzerdefinierte Validatoren entwickeln. Mit Hilfe von sogenannten Dislpay Error
Controls, die neben der Validierung genutzt werden sollten, können dem Benutzer die
entsprechenden Fehlermeldungen flexibler präsentiert werden.
Für die Auswahl der Validatoren ist die Komplexität der Validierung entscheidend. Für
standardmäßige Prüfungen (Kontrolle der vorgeschriebenen Felder oder Datentypkompati-
bilität) in einem K-Pool-Dokument sollten die vordefinierten Validatoren ausreichend sein,
andernfalls ist es geboten, spezifische Validatoren zu entwerfen.
Aufbau und Struktur des XPage-Formulars anpassen
Es ist sinnvoll, die Bereiche wie Header mit Metadaten oder Body mit Inhalt voneinander
zu trennen. Die XPages bieten unterschiedliche Vorgehensweisen an, um den Aufbau zu
modularisieren:
- Panels, deren Layout getrennt voneinander durch CSS formatiert werden kann.
- Auslagern der Bereiche in die Custom Controls; sie sind vorteilhafter im Vergleich zu
den Panels, weil sie mehrmals verwendet werden können und ihre Bearbeitung unab-
hängig von der XPage vonstatten gehen kann.
Ablage (Verwaltung und Archivierung)
Da die Weiterverarbeitung der Dokumente bis jetzt nur im Client durchführbar ist, soll die
Bearbeitung der Dokumente konzipiert werden.
Bearbeiten eines Dokuments
Weil die Inhalte für den Browser in HTML gerendert (übersetzt) werden, können einige
Elemente wie beispielsweise eingebettete Views oder Tabellen nach der Bearbeitung ver-
fälscht werden oder sogar verloren gehen, da sie hernach nicht mehr angezeigt werden
können. Das Risiko des Informationsverlustes kann durch einige Erweiterungen oder zu-
sätzliche Prüfungen der Dokumente gesenkt werden.
27 Darstellung des Konzepts
- Nutzung der htmlConversionWarning-Einstellungen für das RichText-Feld. Die War-
nung (siehe die Abbildung) wird beim Speichern eines Dokuments mit HTML-Inhalt
automatisch ausgegeben.
Abbildung 12: Warnungsmeldung bei "HTML-Conversion"
- Flag-Variable, welche die Editierung im Web erlaubt oder verbietet, sowie in K-
Object Form als auch in XPage vergeben. Damit die vorhandenen Dokumente nicht
zufällig durch inkorrekte Daten überschrieben werden, sollte ein Agent sämtliche vor-
handenen Dokumente mit einem Flag zum Verbieten der Web-Editierung erweitern.
- Nur die Bearbeitung der Metadaten und Attachments zulassen.
Die ersten beiden Alternativen lösen das Problem nicht konsequent, sondern übertragen
das Risiko auf den Benutzer. Die Implementierung dieser Funktion hängt von der User-
Akzeptanz ab, inwieweit die Einschränkungen toleriert werden.
Kommentieren im Web
- Ein XPage-Formular für die Kommentaraufnahme wird benötigt.
- Die Gelegenheit zum Aufrufen des oben genannten Formulars sollte einem angemel-
deten Nutzer zur Verfügung stehen (bzw. zum Anmelden auffordern). Darüber hinaus
ist es sicher erforderlich, die Einstellparameter in den Metadaten des Dokuments zu
prüfen, welche die Kommentierung verbieten können.
Löschen der Dokumente im Web
- Funktion zum Löschen direkt in der Dokumentenansicht bereitstellen.
- Die View-Ansicht könnte eine Funktion bieten, die selektierte Dokumente entfernt.
Diese Funktionen können nebeneinander realisiert werden und sollten aus Sicherheitsgrün-
den nur den autorisierten Benutzern zur Verfügung stehen.
Speicherung und Archivierung der Dokumente in der Datenablage des K-Pools
Durch die Verknüpfung der Form für Dokumente und Kommentare mit entsprechenden
XPages wird der Zugriff auf die Dokumente und ihrer Kommentare sowohl innerhalb des
Clients als auch im Web realisiert.
Anzeige (Recherche und Präsentation)
Die vorhandenen Web-Views können in XPages nicht eingesetzt werden, da sie Fragmente
von HTML Code der Web-K-Pool Page enthalten, deswegen ist es erforderlich, neue
Views zu erstellen. Insofern bieten sich folgende Alternativen zur Umsetzung an:
28 Darstellung des Konzepts
- Separate XPages für jede View anlegen.
- Views auf Custom Controls einbetten, diese auf einer XPage dynamisch in Abhängig-
keit vom Kontext laden. Die Steuerung kann durch eine URL-Referenzierung oder
auch durch das Setzen von globalen ScopeVariablen, die in einer ScriptLibrary initia-
lisiert und im Code der XPages genutzt werden können, geschehen.
Die erste Alternative ist im Sinne der Implementierung und Handhabung einfacher, denn
jede XPage ist über eine feste URL aufrufbar. Die zweite Alternative ist eleganter und effi-
zienter im Sinne der Erweiterungsfähigkeit. Des Weiteren lässt sich dadurch der partiale
Refresh der Seite realisieren, jedoch ist diese Variante auch komplexer hinsichtlich der
Handhabung und Wartung.
View-Navigation / View-Exploration
Die XPages bieten eine Möglichkeit, die Anzeige der kategorisierten Views auf bestimmte
Kategorien zu filtern. Die gesuchte Kategorie könnte wie gewohnt durch ein Suchfeld ein-
gegeben werden, oder auch durch das Anklicken eines Verweises aus den Dokumenten
oder der View gewählt werden. Der Wert der gewählten Kategorie muss dem CategoryFil-
ter in View Properties (Einstellungen) übergeben werden. Dieser könnte mittels URL-
Referenzierung oder mit Hilfe des Setzens der Scope Variablen übergeben werden, wobei
die erste Alternative eine Neuladung der Seite erfordert.
Um die Eingabe des Wertes zu vereinfachen, drängt sich der Einsatz der Typeahead Funk-
tionalität der XPages nahezu auf. Zu diesem Zweck ist ein Lookup auf die Kategorien aus-
zuführen.
Die alphabetische Leiste zu View-Exploration und die Anzeige des Pfades könnten sich
dynamisch an den Kontext anpassen, was mit AJAX realisiert werden könnte.
Volltextsuche
Da die aktuelle Volltextsuche auf der Basis der Domino-Search-Engine realisiert worden
ist und nicht in die XPages integriert werden kann, ließe sich ein neues Formular mit ent-
sprechenden Suchmechanismen entwickeln, die auf die Inhalte der Dokumente zugreifen.
Tag Clouds
Um das Web-Frontend mit Tag Clouds zu erweitern, müsste ein Konzept erzeugt werden,
in dem die unterschiedlichen Varianten der Tag Clouds und mögliche Alternativen zur
Anzeige und Berechnung der aktuellen Tags analysiert und gewählt werden können. Dies
würde den Rahmen dieser Arbeit sprengen und wird aus dem Grunde nicht weitergeführt.
Die Präsentation im Web kann sich in die Anzeige der Dokumente, Kommentare und
Views und in die allgemeine Darstellung (Layout) des Webfrontends unterteilen.
29 Darstellung des Konzepts
Dokumente präsentieren
Durch die Verknüpfung der Felder einer Form mit den Feldern der XPage wird eine Ver-
bindung aufgebaut, die erlaubt, die Inhalte der Items und Felder zu visualisieren. Da die
Präsentation in Abhängigkeit von dem Modus des Dokumentes (Create-, Read- oder Edit-
modus) variiert, müssen diese Modi berücksichtigt werden. Es bietet sich Folgendes an:
- Erstellung von getrennten XPages für neue und vorhandene Dokumente.
- Unterteilung der entsprechenden Bereiche (z.B. ein Dokumenten-Header zum Erstel-
len und Bearbeiten und einer zum Anzeigen) auf einer XPage durch Panels oder Cus-
tom Controls und dynamische Berechnung ihrer Sichtbarkeit während der Laufzeit.
- Bestimmung der Sichtbarkeit auf der Feldebene in Abhängigkeit von dem Modus.
Die ersten beiden Alternativen sind einfacher im Hinblick auf die Implementierung, sie
sind jedoch mit Redundanz verbunden. Die dritte Variante ist freundlicher im Sinne der
Überschaubarkeit, da die Struktur des Dokuments erkennbar bleibt. Diese Variante sollte
bevorzugt werden, wenn Übersichtlichkeit und Wartungsfreundlichkeit im Vordergrund
stehen. Die zweite Alternative könnte dann in Betracht gezogen werden, wenn die Priorität
auf der Wiederverwendbarkeit der Elemente liegt oder die Bereiche in verschiedenen Modi
unterschiedlich gezeigt werden sollen.
Anzeige des Dokumentenkopfs steuern
Wie in der Beschreibung des K-Pools bemerkt, kann die Anzeige des Dokumentes benut-
zerdefiniert durch die Auswahl der entsprechenden Funktionalitäten in Menü-Leiste der
Webseite gesteuert werden. Dies kann auch mit XPages realisiert werden, indem die Sich-
tbarkeit des Dokumenten-Headers programmatisch durch SessionScope-Variablen ge-
steuert wird. Die Scope-Variablen werden in der ScriptLibrary initiiert und durch das Ank-
licken eines entsprechenden Links vom Benutzer neu gesetzt.
Kommentare anzeigen
Um die Liste der Kommentare zu dem Dokument aufzurufen, bieten die XPages Data
Table und Repeat Control an. Die Auswahl hängt von den Designvorstellungen des Ent-
wicklers ab. Zu beachten ist, dass JavaScript nur die Möglichkeit bietet, die Kommentare
erster Ebene anzuzeigen. Folgende Alternativen stehen zur Verfügung:
- Mittels Lookup auf eine nach Dokument UNID kategorisierte View, die alle Doku-
mente und deren Responses (Antworten) enthalten soll, kann die Datenquelle des
Controls die zugehörigen Kommentare „anbinden“.
- Rekursive Funktion entwickeln, welche die Collection der Dokumente generisch be-
rechnet, so dass alle Ebenen der Kommentare unterbreitet werden können.
30 Darstellung des Konzepts
Des Weiteren sind die Benutzereinstellungen (Web-Settings Tab) in den Dokumenten zu
beachten, die z.B. die Anzeige der Kommentare im Web verbieten können. Darüberhinaus
könnte man die Anzeige der Kommentare direkt in dem Dokument integrieren, was die
Benutzerfreundlichkeit erhöhen und das zusätzliche Laden neuer Seiten vermeiden würde.
Views darstellen
Die Views sollten weiterhin so gestaltet werden, dass sie eine Übersicht auf das Dokument
geben und eine Navigation zu weiteren Kategorien ermöglichen. Für die Umsetzung bieten
sich View Controls, Data Table oder Repeat Controls an. Jede Variante ist umsetzbar, wo-
bei die letzten beiden Controls etwas flexibler gestaltet werden können, jedoch bieten sie
keine automatisierte Kategoriefilterung wie die erste Alternative.
Layout des Web-Frontends kreieren
Da fast alle Elemente der XPages dynamisch berechnet und erweitert werden können, bie-
ten XPages sehr viele Gestaltungsmöglichkeiten eines Web-Frontends. Zu berücksichtigen
ist die benutzerdefinierte Steuerung des Aussehens aus dem Web Setting-Dokument. Die-
ses müsste erweitert werden, um die eingestellten Parameter in passendem Format für die
XPages bereitzustellen (CSS oder HTML).
Außerdem gäbe es die Möglichkeit, die Layout-Einstellungen in einer CSS-Datei zu ver-
walten, was eine Alternative zu dem Web Settings-Dokument wäre; es erfordert jedoch
CSS-Kenntnisse für eine benutzerdefinierten Anpassung. Eine Alternative dazu wäre die
Einstellungen direkt in dem CSS-Editor der Controls vorzunehmen.
In Hinblick auf die zukünftigen Entwicklungen scheint die CSS-Variante eine bessere
Wahl zu sein, da die Web Settings durch die Erweiterungen zu unübersichtlich werden und
ihren Zweck nicht mehr erfüllen können.
Administration
Für die Umsetzung der Zugriffsregelungen im Web können die XPages die üblichen Lotus
Notes/Domino-Sicherheitsmechanismen und das Rollenkonzept der ACL nutzen, um einen
sicheren Zugriff auf die Inhalte zu gewährleisten.
- Eine sichere Anmeldung könnte weiterhin über die SSL27
realisiert werden.
- Die Zugriffe auf die Inhalte und Funktionalitäten können durch einen Vergleich der
Rechte in ACL für die jeweiligen Benutzer gesteuert werden. Zu diesem Zweck stehen
die JavaScript Klassen und @Functions bereit.
27
Secure Sockets Layer schützt die Kommunikation und Authentifizierung mit Server (IBM Corporation,
2009)
31 Prototypische Realisierung
4 Prototypische Realisierung
In diesem Kapitel soll die Umsetzung der Lösung vorgestellt werden. Das Ziel ist, die Be-
sonderheiten des Prototyps vorzustellen und eine abschließende Reflektion der Ergebnisse
und gewonnener Erkenntnisse in einem Fazit vorzunehmen.
4.1 Vorstellung des neuen Web-Frontends
Bevor die Umsetzung der Anforderungspunkte und die auftretenden Probleme näher be-
schrieben werden, sollen überblicksartig die neuen Funktionalitäten und Erweiterungen des
K-Pools vorgestellt werden.
Die neue Benutzeroberfläche des K-Pools besteht im Grunde aus den gleichen Bereichen
wie das aktuelle Web-Frontend. Der Header ermöglicht die Navigation innerhalb der
Web-Seite und die Menü-Leiste bietet die Auswahl der Ansichten sowie die Einstellungen
zum Anzeigen bzw. Verbergen des Dokumenten-Headers. Der Benutzer hat weiterhin die
Möglichkeit in den Views zu Navigieren, die Dokumente zu suchen und anzuzeigen.
Abbildung 13: K-Pool mit XPages
Die Recherche kann wie gewohnt über Themes, Keywords und Meta Structures erfolgen.
Darüber hinaus wird der Benutzer bei der Suche nach Inhalten mit Begriffsvorschlägen
unterstützt (siehe die Abbildung 13), was die Benutzerfreundlichkeit erhöht. Während der
Eingabe des Suchbegriffs wird in Abhängigkeit von der Ansicht eine Liste der Vorschläge
angeboten. Dabei richtet sich die Anzeige der Begriffsvorschläge nach der bis dahin einge-
gebenen Zeichenfolge. Wird der gesuchte Begriff nicht angezeigt, so bedeutet dies, dass er
32 Prototypische Realisierung
nicht als Keyword vorhanden ist und auf ein erneutes Laden der Seite bei der Suchanfrage
kann verzichtet werden.
Um den Benutzer von der Lotus Notes Umgebung unabhängig zu machen, wurde K-Pool
mit der Möglichkeit der Erstellung bzw. Bearbeitung der Dokumente erweitert. Das For-
mular zur Anfertigung neuer Dokumente kann aus der Menüleiste aufgerufen werden, wo-
bei die anonymen Benutzer zur Anmeldung auf dem Server aufgerufen werden. Die Struk-
tur des neuen Formulars ist ähnlich wie die der Form im Client, so dass der Anwender Be-
nutzer in einer gewohnten Umgebung arbeiten kann. Alle Felder für Metadaten und Kate-
gorisierungsmöglichkeiten wie Themes, Keywords, Titel und kurze Beschreibung stehen
auch bei der Indizierung des Dokuments im Web zur Verfügung. Bei der Eingabe der
Keywords wird sowohl Taxonomy als auch Folksonomy unterstützt, indem der Benutzer
bestehende Keywords aus einer Vorschlagsliste übernehmen kann oder auch eigene Werte
in das Feld eingeben darf.
Die verbesserten Funktionalitäten zum Hinzufügen und Anzeigen der Attachments erlau-
ben einen Upload mehrerer Dateien gleichzeitig und vereinfachen die Bedienung für den
Benutzer. Wie in dem folgenden Ausschnitt zu sehen ist, können durch das Betätigen des
„+“ Buttons weitere Upload-Felder hinzugefügt werden.
Abbildung 14: Hinzufügen von Attachment zum Dokument
Die Inhaltstexte sowie die „additional information“ können in den RichText-Editoren ein-
gegeben und beliebig formatiert werden. Die vorgenommene Formatierung und die hinzu-
gefügten Attachments sind sowohl im Browser als auch im Notes Client sichtbar. Die Do-
kumente werden in der zentralen Ablage des K-Pools gespeichert und stehen im Client und
auch im Web zur Anzeige oder Bearbeitung bereit.
Bei der Präsentation eines Dokuments werden die Metadaten, der Inhalt sowie die Kom-
mentare und Attachments zu dem Dokument dargestellt, darüber hinaus ist eine Funktion
zum Editieren der Dokumente vorhanden. Die Bearbeitung der Dokumente ist aus Sicher-
heitsgründen nur den angemeldeten Benutzern, unter Berücksichtigung der Einstellungen
in den Metadaten des Dokuments, möglich. Versucht ein Anwender die Dokumente mit
Tabellen oder sonstigen Inhalten, die in HTML konvertiert wurden, zu bearbeiten und ab-
33 Prototypische Realisierung
zuspeichern, wird er über die Risiken des Informationsverlustes informiert und kann ent-
scheiden, ob die Aktion abgebrochen oder das Dokument abgespeichert werden soll.
Die folgende Abbildung präsentiert die Darstellung eines Dokuments im Web.
Abbildung 15: Darstellung eines XPage-Dokuments
Das neue Web-Frontend wartet auch mit der Möglichkeit der Anzeige, dem Verfassen und
der Bearbeitung von Kommentaren auf, wobei die Funktionalitäten unter Beachtung der
Web-Einstellungen des Dokuments, welches kommentiert werden soll, zur Verfügung ste-
hen. Die Kommentare zu dem Dokument werden, wie in der Abbildung 15 zu sehen ist, in
einer hierarchischen Liste angezeigt. Durch die entsprechenden Links in der Action-Leiste
des Dokuments bzw. des Kommentars kann ein Formular aufgerufen werden, wodurch das
Verfassen neuer oder die Bearbeitung vorhandener Kommentare gegeben ist wird. Dem
Benutzer wird die Option zur Verfügung gestellt, den eingegebenen Text beliebig zu for-
matieren und abzuspeichern sowie die Attachments hinzuzufügen.
4.2 Beschreibung der Umsetzung
Um die Nutzenpotenziale der XPages für ein DMS zu analysieren, wurde in erster Linie
danach getrachtet, die aktuellen Funktionalitäten des K-Pool Web-Frontends so weit wie
möglich nachzubauen bzw. zu erweitern. Die Anforderungen und die Konzeption stellten
dabei eine Grundlage dar.
34 Prototypische Realisierung
Eingabe (Eingang und Indizierung)
Um die Anforderungen an die Erstellung und Indizierung neuer Dokumente zu erfüllen,
wurde ein XPages-Formular entwickelt. Wie im Konzept beschrieben, wurden bei der Um-
setzung die Bereiche des Dokuments in einzelne Custom Controls auslagert, mit dem Ziel-
einen modularen Seitenaufbau zu offerieren und so die Wartung und Pflege zu erleichtern.
Der Metadaten-Bereich wurde am Beispiel der GCC_NC_LTT_Standard Subform entwor-
fen. Des Weiteren wurden für den Prototyp die im Konzept beschriebenen LotusScript-
Funktionen für die Eingabe der Themes, Keywords und Meta Structures mittels der Lis-
tenboxen und Lookups auf die entsprechenden Kategorien simuliert und in dem Metada-
ten-Bereich des Dokuments dargeboten.
Damit die eingegebenen Metadaten dynamisch in dem Kopfbereich des Dokuments zur
Anzeige übernommen werden, wurde AJAX Partial Refresh eingesetzt, so dass nur das
notwendige Panel geladen wird. Dies erhöht die Benutzerfreundlichkeit und vermeidet das
komplette Laden der ganzen Seite.
Für die Anzeige der Metadaten in dem Dokumentenkopf als Hyperlinks wurde eine Funk-
tion angefertigt, welche die entsprechenden Kategorien durch Listen-Operationen bearbei-
tet und formatiert als Hyperlinks ausgibt.
Das Hinzufügen von Attachments und Thumbnails wurde, wie im Konzept vorgeschlagen,
mit Hilfe von FileUpload und FileDownload Controls weitgehend umgesetzt. Mit der Ab-
sicht, die Benutzerfreundlichkeit bei dem Hinzufügen von Attachments zu erhöhen, wurde
die Funktion durch Einsatz von Repeat Controls so erweitert, dass der User mehrere Up-
loads gleichzeitig durchführen kann.
Um die Anforderungen an die Erstellung neuer Dokumente zu erfüllen, fehlen dem Proto-
typ die Kontrolle der Benutzerrechte im System sowie die Validierung der Benutzereinga-
ben beim Speichern.
Ablage (Verwaltung und Archivierung)
In dem Konzept (siehe Kapitel 3.3) wurde ein mögliches Problem bei der Editierung im
Web erwähnt und es wurden alternative Methoden zur Lösung dieses Problems aufgeführt.
Allerdings haben sämtliche Alternativen ihre Nachteile und würden das Problem nicht
wirklich lösen. Damit die Nutzenpotenziale der XPages für ein DMS besser analysiert
werden können, wurde diese Funktionalität jedoch implementiert. Als Formular wird die
XPage zum Erstellen und Indizieren der Dokumente verwendet, welche aus ähnlichen Be-
reichen besteht, so dass viele Funktionalitäten wiederverwendet werden können. Jedoch
35 Prototypische Realisierung
wurde die Metadaten-Tabelle um einen History-Tab erweitert, welcher nur im Editiermo-
dus für die Dokumente mit mehreren Versionen angeboten wird.
Für die prototypische Umsetzung wurde die Eigenschaft der XPages vorgezogen, welche
eine automatische Warnung beim Bearbeiten von HTML-konvertierter Inhalte ausgibt.
Hierzu wurde die htmlConversionWarning-Einstellung in den RichText-Feldern entspre-
chend konfiguriert. Zusätzlich, um das Risiko des Informationsverlustes zu minimieren,
wurde das Dokument (XPage und K-Object-Form) mit einem Auswahlfeld erweitert. In
Abhängigkeit von dem Wert in diesem Feld kann ein Dokument von der Bearbeitung im
Web ausgeschlossen werden.
Um die Anforderungen zu erfüllen, fehlen dem Prototyp die Funktion zum Löschen der
Dokumente im Web und die Berücksichtigung der Zugriffsrechte für die Editierung der
Dokumente. Des Weiteren sollte das Versionsmanagement angepasst werden, so dass auch
im Web die Möglichkeit gegeben wird, neue Versionen eines Dokuments anzulegen.
Ausgabe (Recherche und Präsentation)
Navigation und Recherche
Wie in der Konzeption beschrieben, wurden für die XPages neue Views erstellt, welche bei
der Umsetzung der Navigation in den Kategorien verwendet werden. Bereits in den Views
wird darauf geachtet, dass nur berechtigte Dokumente im Web erscheinen und die internen
Dokumente aus Sicherheitsgründen verborgen werden.
Bei der Implementierung dieser Views auf XPages entstand ein Problem mit der mehrfa-
chen Kategorisierung. Die vorhandene categoryFilter-Funktionalität der View Controls
ermöglicht in der aktuellen Version lediglich die Navigation in der ersten Kategorie-Ebene
der Views. Aus diesem Grund wurde eine Funktion entwickelt, welche die Kategorien der
Dokumente mit Hilfe von Listen-Operationen ausliest und bearbeitet. Als Ergebnis liefert
diese Funktion eine Liste der Hyperlinks zu den Kategorien der aktuellen Ebene.
Bei dem Laden der Webseite im Browser, werden die notwendigen Variablen initialisiert,
so dass die aktuellen Parameter (Kategorie, View und Ebene) gespeichert werden. Des
Weiteren wird dynamisch ein Pfad berechnet und ausgegeben, so dass auch die „Rückna-
vigation“ ermöglichet wird.
Sobald eine Kategorie einzelne Dokumente enthält, werden diese in einer View dargestellt.
Dafür wurde ein View Control mit einer dynamischen Berechnung der Datenquelle im-
plementiert, sodass zur Laufzeit entschieden wird, aus welcher Notes-View die Daten
übernommen werden sollen. Die Übergabe der Parameter erfolgt über die URL-
Referenzierung, sodass jederzeit die aktuelle View und Kategorien geladen werden.
36 Prototypische Realisierung
Weiterhin wurde ein Feld zur Eingabe eines Suchparameters implementiert und mit der
Typeahead-Funktionalität ausgestattet. Dafür wird ein Lookup auf die Kategorien der ak-
tuellen View durchgeführt. In der folgenden Abbildung wird der Ablauf der Funktion zur
View-Navigation visualisiert.
Abbildung 16: Ablaufdiagramm zu der View-Navigation
Die Vorteile dieser Lösung sind in der dynamischen Bindung zu sehen, was eine kontext-
abhängige Anzeige der Informationen ermöglicht und eine redundante Erstellung ähnlicher
Elemente vermeidet. Jedoch hat diese „Umweg-Lösung“ auch Nachteile, sie liegen in der
Darstellung der Kategorienliste. Bei vielen Dokumenten und Kategorien würde diese Liste
sehr lang werden und die Suche erheblich erschweren oder sogar unmöglich machen.
Um eine benutzerfreundliche Arbeit mit dem DMS zu gestatten, sollte diese Lösung weite-
rentwickelt bzw. verbessert werden, was z.B. durch Verwendung eines Repeat Controls
oder Data Tables für die Ausgabe der Kategorienliste geschehen könnte.
Des Weiteren sollte die View-Exploration implementiert sowie die Volltextsuche in das
Web-Frontend des K-Pools integriert werden, um die Anforderungen an die Lösung zu
erfüllen.
Präsentation
Für das Layout des Web-Frontends wurde ein (KPoolLayout) Template entwickelt, wel-
ches durch CSS-Formatierung die Struktur des Web-Frontends vorgibt. Die Inhalte werden
erst bei der Implementierung auf der XPage hinzugefügt, was mit Hilfe von Editable Areas
37 Prototypische Realisierung
realisiert wurde. Die unten stehende Abbildung Nr. 17 zeigt beispielhaft, dass durch die
Implementierung unterschiedlicher Custom Controls mehrere Webseiten mit Hilfe des
Templates erstellt werden können. Die Vorteile dieser Lösung liegen in der einfachen und
schnellen Entwicklung benutzerdefinierter Web-Frontends für den K-Pool, was die Wie-
derverwendbarkeit des DMS unterstützt.
Abbildung 17: Template für K-Pool Layout
Für die linke Navigationsleiste des Web-Frontends wurde das Web-Settings-Dokument
angepasst, sodass die Hyperlinks auf die Kategorien und externe Webseiten dynamisch
ausgelesen und angezeigt werden. In Weiterem wurden die Funktionalitäten zum Steuern
der Anzeige von Dokumenten-Headern realisiert. Durch das Anklicken der Links wird der
Wert einer Scope-Variable, die bei dem Laden der Webseite initialisiert wird, neu gesetzt
und in den Sichtbarkeit-Einstellungen des Dokumenten-Header Controls berücksichtigt.
Wie in der Abbildung Nr. 15 zu sehen ist, wird eine Liste der Kommentare präsentiert,
dafür wurde eine rekursive Funktion entwickelt, welche eine hierarchische Darstellung
aller Antworte erlaubt, indem sie eine Liste der Antworte aller Ebenen aufbaut. Hierbei
wird die Einstellung (No access for Webbrowsers) in dem Kommentar überprüft und be-
rücksichtigt, so dass nur erlaubte Kommentare als Hyperlinks visualisiert werden.
Administration
Für die Umsetzung der Anmeldung wurde ein Link in der Menü-Leiste erstellt, so dass der
Benutzer sich auf dem Server anmelden kann. Die Funktionalitäten, wie das Erstellen
bzw. Bearbeiten der Dokumente oder Kommentare, stehen den angemeldeten Benutzern
zu Verfügung. Um die Anforderungen an die Sicherheit zu erfüllen, fehlt dem Prototyp die
Kontrolle der Zugriffsrechte.
4.3 Ausblick
Die Anforderungen konnten weitgehend umgesetzt werden, jedoch bietet der Prototyp
noch zahlreiche Verbesserungsoptionen. Es sind hauptsächlich die optischen Anpassungen
38 Prototypische Realisierung
der Formulare und der Darstellung. Des Weiteren sollten die Validierung der Benutzerein-
gaben und die Kontrolle der Zugriffsrechte bei der Erstellung oder Bearbeitung der Doku-
mente umgesetzt werden.
Die Übernahme der Meta Structures und Keywords in die Dokumente könnte durch den
Einsatz von Dialogboxen benutzerfreundlicher und interaktiver gestaltet werden. Darüber
hinaus könnte eine Auswahl der zusätzlichen Metadaten-Arten (wie z.B. Literaturangaben)
realisiert werden, um den Anwender bei der Erstellung der Dokumente nicht auf die Stan-
dard-Metadaten einzugrenzen.
Weitere Verbesserungsmöglichkeiten sind in der Integration der Volltextsuche und in der
Dynamisierung der Recherchemechanismen des Web-Frontends zu sehen. Eine kontextab-
hängige Anzeige der alphabetischen Leiste (View-Exploration), sowie die Weiterentwick-
lung der View-Navigation (Aufteilen der dargestellten Kategorienliste auf mehrere Seiten),
würden dem Benutzer die Informationssuche wesentlich erleichtern.
Um die Wiederverwendbarkeit des K-Pools zu erhalten, könnte das Web-Settings-
Dokument um die Einstellungen für die XPages erweitert und bei der Gestaltung des
Layouts des Web-Frontends berücksichtigt werden.
Eine Bereicherung des Web-Frontends mit modernen Web 2.0-Funktionalitäten wie Tag-
Clouds könnte vorgenommen werden. Die kontextabhängige Anzeige der Schlagwörter
oder der meistbesuchten Kategorien, aber auch die Liste der zuletzt erstellten Dokumente
und Kommentare würden dem Benutzer einen besseren Überblick bieten und ihn bei der
Informationssuche unterstützen. Zusätzliche Mechanismen wie das Senden eines Links
per E-mail, das Bewerten der Dokumente und Kommentare, das Setzen der Bookmarks
(Favoriten) und das Abonnieren von News-Feeds mit neun Inhalten würden die Arbeit im
K-Pool bequemer gestalten und einen erheblichen Mehrwert generieren.
4.4 Nutzenpotenziale der XPages (Fazit)
Das Ziel dieser Bachelorarbeit war, die Nutzenpotenziale der XPages für ein DMS zu er-
forschen und zu analysieren. Im Mittelpunkt standen die Konzeption und Implementierung
eines neuen Web-Frontends für ein auf Lotus Notes/Domino basierendes DMS.
Bedingt durch die Konzeption und die Umsetzung offenbarten sich die vielfältigen Gestal-
tungsmöglichkeiten der XPages. Durch die dynamische Verknüpfung von mehreren Da-
tenquellen auf einer XPage, entstehen völlig neue Darstellungsmöglichkeiten für die Do-
kumente und Views. Es ist z.B. gestattet möglich, Daten mehrerer Dokumente auf einer
Seite zu vereinen und als Ganzes zu speichern. Der Zugriff auf eine breite Palette an mög-
39 Prototypische Realisierung
lichen Controls erlaubt die Entwicklung moderner Web-Applikationen, deren Umfang den
Client-Anwendungen ähnlich ist.
Die Realisierung solcher Funktionalitäten wie das Erstellen und Bearbeiten der Dokumente
im Web lässt dem Nutzer eines DMS sehr viel mehr Flexibilität und Unabhängigkeit von
der Systemumgebung zuteil werden. Dies erfordert jedoch die Toleranz gewisser Ein-
schränkungen der aktuellen Version der Entwicklungsumgebung wie das Risiko des In-
formationsverlustes bei der Bearbeitung und Speicherung HTML-gerenderter Inhalte oder
die beschränkte Gestaltungsmöglichkeit der Dokumente mit Tabellen oder ähnlichen
Strukturen.
Weitere Vorteile liegen in der modularen Struktur der XPages, die durch unterschiedliche
Panels und Custom Controls gegeben ist. Da sich die einzelnen Bereiche unabhängig vo-
neinander bearbeiten und steuern lassen, wird die Basis für eine Entwicklung dynamischer
Seiten mit kontextabhängiger Anzeige der Informationen bereitet.
Die XPages verbinden etablierte Vorteile der Notes-Funktionalitäten mit modernen Web
2.0-Elementen wie AJAX und Dojo. Diese geben auf der einen Seite dem Entwickler die
Möglichkeit, fortgeschrittene und trendige Web-Frontends für ein DMS mit Hilfe von be-
währten Technologien zu gestalten. Auf der anderen Seite profitieren die Benutzer von der
vereinfachten und benutzerfreundlichen Interaktion mit dem System.
Die im Kapitel 2.5.1 beschriebenen Designelemente „Themes“ geben dem Entwickler neue
Möglichkeiten, um das Aussehen der Applikation flexibler zu arrangieren und eine benut-
zerdefinierte Lokalisierung zu realisieren, um beispielsweise ein DMS in unterschiedlichen
Sprachversionen bereitzustellen. Dies würde die Wiederverwendbarkeit des Systems för-
dern und einen erheblichen Mehrwert beinhalten.
Abgesehen von den angesprochenen Vorteilen lässt sich auch eine Reihe von Nachteilen
anführen. Sie liegen aktuell zum einen in der nicht fehlerfrei funktionierenden Entwick-
lungsumgebung, die sich beispielsweise in der eingeschränkten Kategorie-Filterung der
View Controls bemerkbar macht, welche zur Entwicklung zusätzlicher, aufwendiger Kons-
trukte führt, um den Anwender nicht bei der Suche nach Informationen in einem DMS
einzuschränken. Zum anderen besteht ein Nachteil in der unzureichenden öffentlichen Do-
kumentation und fehlenden Debugging-Möglichkeit bei der Fehlersuche, was die Entwick-
lung wesentlich erschwert.
40 Zusammenfassung
5 Zusammenfassung
In der vorliegenden Arbeit wurde ein Konzept zur Umstellung des Web-Frontends eines
DMS auf XPages erstellt und prototypisch implementiert.
Zu diesem Zweck wurden zunächst in dem zweiten Kapitel die grundlegenden Begriffe
behandelt, um eine Basis für weitere Untersuchungen zu bereiten. Die Funktionen der
DMS, die für die Erstellung der Anforderungen an die Lösung unerlässlich waren, wurden
betrachtet und definiert. Die Einsicht in die funktionalen und technischen Seiten der XPa-
ges war vorrangig für die Konzeption und prototypische Realisierung von Bedeutung.
Weiterhin wurde im dritten Kapitel die Systemumgebung GCC K-Pool, welche die Grund-
lage für die Implementierung war, vorgestellt und die Besonderheiten des Web-Frontends
wurden untersucht. Anschließend konnte ein Anforderungskatalog für die Lösung erstellt
werden. Er basiert auf den vorherigen Betrachtungen der Funktionen der DMS in Allge-
meinem und des GCC K-Pools in Besonderem. Es konnte ein umfassendes Konzept zur
Umsetzung definierter Anforderungen erstellt werden, in dem die unterschiedlichen Mög-
lichkeiten und Maßnahmen vermittelt und analysiert wurden.
In dem vierten Kapitel erfolgte die Beschreibung der prototypischen Implementierung.
Einleitend wurden die Funktionalitäten des neuen Web-Frontends präsentiert. Anschlie-
ßend wurde die Umsetzung beschrieben, indem die Besonderheiten und Probleme aufge-
führt wurden, die bei der Implementierung entstanden. Zusammenfassend lässt sich be-
merken, dass die Anforderungen an die Lösung weitgehend erfüllt werden konnten. Der
vorgestellte Prototyp bietet eine gute Basis für weitere Entwicklungen in diesem Bereich.
In einem Ausblick wurden mögliche Verbesserungs-und Erweiterungsmöglichkeiten refe-
riert. Die Reflexion der Nutzenpotenziale der XPages für ein DMS den Abschluss dieser
Arbeit.
41 Literatur
6 Literatur
Avci, O. / Trittmann, R. / Mellis, W. (2003): Web Programmierung. 1. Auflage, Vieweg,
Wiesbaden 2003
Binsack, F./Golmick, M. (2008): Meilenstein in der Anwendungsentwicklung. Erschien
in: Digital Business Magazine, (6/2008) Nr. 94, S. 14-16.
Bodendorf, F. (2006): Daten-und Wissensmanagement. Zweite aktualisierte und erweiter-
te Auflage, Springer, Berlin Heidelberg 2006
Bosch, A. (2004): Java Server Faces: Das Standard-Framework zum Aufbau webbasierter
Anwendungen. Addison-Wesley, München 2004
Ekert, T. (2006): Java unter Lotus Domino. 1. Auflage, Springer, Berlin Heidelberg 2006
Gehtland, J./Galbreith, B./Almaer, D. (2006): AJAX. Eine programmatische Einführung
in Web 2.0. 1.Auflage, Hanser Verlag, München Wien 2006
Götzer, K./Komke, T./Maier, B./Schneiderath, U. (2004): Dokumenten-Management.
3. Auflage, dpunkt, Heidelberg 2004
Gulbins, J./Seyfried, M./Strack-Zimmermann, H. (2004): Dokumenten Management. 2.
Auflage, Springer, Berlin Heidelberg 1999
Hass, B./Kilian, T./Walsh, G. (2007): Web 2.0: Neue Perspektiven für Marketing und
Medien.1. Auflage, Springer, Berlin Heidelberg 2007
Hesse, B. (2006): GCC K-Pool-Integriertes Wissens-und Dokumentenmanagement auf
Instituts-und Fakultätsebene. [Online] [letzter Zugriff: 19.01.09]
http://gcc.uni-paderborn.de/www/WI/WI2/wi2_lit.nsf/KPoolThemes/76681D46C83A8
E9CC12571950077CDF4?OpenDocument
Hoffmann, M.(2008): Modernes Webdesign. Gestaltungsprinzipien, Webstandards, Pra-
xis. 1. Auflage, Galileo Press, Bonn 2008
IBM Corporation (2008): IBM Readme 8.5 Beta [Online] [letzter Zugriff: 20.12.08]
http://www-10.lotus.com/ldd/nd85forum.nsf/0/0efc82dac98270ff852574580060a1ba/
$FILE/readme_85_beta.pdf
42 Literatur
IBM Corporation (2009): IBM Information Center. [Online] [letzter Zugriff: 20.01.09]
http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp
Kampffmeyer, U. (2003): Dokumenten-Technologien: Wohin geht die Reise? 1. Auflage,
Project Consult, Hamburg 2003
Kampffmeyer, U/Merkel, B. (1999 ): Grundlagen des Dokumentenmanagements.1. Auf-
lage, Gabler, Wiesbaden 1999
Kulkarni, A. (2008): New Editors in Domino Designer 8.5 [Online] [letzter Zugriff:
15.12.08] http://www-10.lotus.com/ldd/ddwiki.nsf/dx/11192008104656AMAAKLHL.htm
Lenz, M. (2008): Lotus Notes/Domino. [Online] [letzter Zugriff: 28.01.09]
http://www.hamburger-notes-netzwerk.de/we4it/timetoweb.nsf/5a419d474f3279b3c1256
c09002f3b2a/d0d42b57cbe8ab89c125735b003a9446/$FILE/HANNE.pdf
Maurice, F. (2007): Web 2.0 Praxis. 1. Auflage, Markt+Technik Verlag, München 2007
Meinel, C./Sack, H.(2003): WWW: Kommunikation, Internetworking, Web-
Technologien. 1. Auflage, Springer, Berlin Heidelberg 2003
Moussaoui, H. E./Zeppenfeld, K. (2007): AJAX: Geschichte, Technolgie, Zukunft. 1.
Auflage, Springer, Berlin Heidelberg 2007
O’Connor, D. (2008): Data binding in XPages. [Online] [letzter Zugriff: 13.12.08 ]
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/10082008104832AMDOCKD8.htm
O’Reilly, T. (2005): What is Web 2.0? O’Reilly Media [Online] [letzter Zugriff: 19.01.09]
http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html
Pollak, A. (2008): DominoDesigner’s new XPages. [Online] [letzter Zugriff: 20.01.09]
http://www.thenorth.com/northern.nsf/html/XpagesArticle
Rockwell, W. (2000): XML, XSLT, Java und JSP: Professionelle Web-Applikationen
entwickeln. 1. Auflage, Galileo Press, Bonn 2001
Steyer, R. (2000): JavaScript in 21 Tagen. Markt+Technik Verlag, München 2000
Sun Microsystems (2008): The Java EE 5 Tutorial. [Online] [letzter Zugriff: 22.01.09]
http://java.sun.com/javaee/5/docs/tutorial/doc/bnaph.html
43 Literatur
Turau, V./Pfeiffer, R. (2001): Java Server Pages. 2. Auflage, dpunkt, Heidelberg 2001
Wahli, U./Cohen, G./Perrins, M./Sanches Azera, L./Zandersen, M. (2004): WebSphere
Studio 5.1.2 JavaServer Faces and Service Data Objects, IBM 2004 [Online] [letzter
Zugriff: 09.01.09] http://www.redbooks.ibm.com/abstracts/sg246361.html?Open
44 Anhang
7 Anhang
Ergänzend zu den Inhalten dieser Bachelorarbeit sind in dem Anhang zusätzliche Tabel-
len, Abbildungen und Hinweise zu dem Prototyp aufgelistet.
I. Übersicht der LotusScript-Funktionen
Folgende Funktionen zum Erstellen eines neuen Dokuments im Client (K-Object Form)
sollten bei Bedarf fürs Web neu entwickelt werden, da die XPages keine vorhandene Acti-
ons nutzen können. LotusScript wird nicht unterstützt, daher sollten die Funktionen bei
Bedarf in JavaScript umprogrammiert werden.
Action
Bibliothek ( Funktion ) Sprache
Load
NewVersion
Themes
Keywords
Meta Structures
Administration
New Meta Set
Edit Content
Switch Metabox
Header
Change global
Settings
Change Document
Settings
Help
Workflow
Acknowledgement
Initiate (GCC)
Properties
Release
Reserve
Reserve and Status
Additional Tasks
Exceptions
Log
ProzessViewer
Import/Export
Thumbnails
TemplateV5UILib (OpenDialogTemplateTool)
VersionUILib (CreateNewVersion())
GCCThemesUILib (OpenDialogThemesInForm())
KeywordsV5UILib (OpenDialogKeywordsInForm)
CategoriesV5UILib (OpenDialogCategoriesInorm())
AccessUILib (OpenDialogAccessInForm())
in Action implementiert
in Action implementiert
in Action implementiert
in Action implementiert
in Action implementiert
AcknowledgementUILib (OpenDialogReceipt)
wfUIDocument (OpenStartDialog)
wfUIDocument (OpenSettingsDialog )
wfUIDialogSetting (ClickButtonReleaseDoc )
wfUIDialogSetting (Call ClickButtonReserveDoc)
wfUIDialogSetting (OpenWFSettingDialogForm)
wfUIDocument (OpenAdHocDefDialog)
wfUIDocument (OpenExceptionsDialog )
wfUIDocument (OpenLogDialog)
in Action implementiert
GCCThumbnailLib
LS
LS
LS
LS
LS
LS
LS
LS
LS
LS
LS
@Command
LS
LS
LS
LS
LS
LS
LS
LS
LS
LS
LS
45 Anhang
II. Übersicht der erstellten Xpages
XPage Beschreibung Ressourcen
ErrorPage Dient der Fehleranzeige, falls eine Seite nicht
geladen werden kann.
K-Object Dient der Darstellung der Dokumente im
Lese-Modus.
CSS _Style.css
xpGCC_View_Body.jss
K-Object-Edit Formular zum Erstellen bzw. Bearbeiten der
Dokumente
CSS _Style.css
xpGCC_View_Body.jss
K-Object-
NewComments
Formular zum Erstellen bzw. Bearbeiten der
Kommentare.
K-Object-Response Dient zum Anzeigen der Kommentare im
Lese-Modus.
KPool_Start Startseite des K-Pools. Bietet Navigations-
und Recherchemöglichkeiten.
xpGCC_View_Body.jss
xpGCC_ServerSide.jss
View_Navigation Wird in KPool_Start eingebettet und bietet
die View-Navigation.
xpGCC_View_Body.jss
III. Übersicht der Custom Controls
Custom Cont-
rol:
Beschreibung: Verwendet in
actionBar Stellt Links für Erstellen/Bearbeiten der
Kommentare bereit
K-Object.xsp
K-Object-Response.xsp
ariadnePath Zeigt die aktuelle Ebene und bietet Möglich-
keit der “Rücknavigation“
KPool_Start.xsp
Comment_header Zur Anzeige der Metadaten er Kommentare. K-Object-Response.xsp
K-Object-
NewComments.xsp
Comments_List Anzeige der Kommentare als hierarchische
Liste, anhand der initialisierten Scope Variab-
len des „Commenst“ Controls
K-Object-Response.xsp
Comments Initialisiert die Kommentarliste zu dem Do-
kument und schreibt Werte zur Anzeige als
hierarchische Liste in Scope Variablen.
K-Object.xsp
Content_Search Stellt ein Search-Feld zur Suche in den Kate-
gorien. View-Name wird über URL ausgele-
KPool_Start.xsp
46 Anhang
sen und DbColumn auf die Kategorien der
aktuellen View ausgeführt. Wert wird in einer
Scope-Variable gespeichert und über URL
referenziert.
Doc_header_read Zur Anzeige der Metadaten in dem Dokumen-
tenkopf. Nutzt Funktionen in ScriptLibrary
xpGCC_View_Body.jss zum Anzeigen der
Liste von Themes, Keywords oder Metastruc-
tures als Links
K-Object.xsp
K-Object-Edit.xsp
Footer Dient , wie der Name sagt als Footer In jeder Xpage
GCC_header Enthält GCC Logo und soll der Navigation
innerhalb der GCC-Webseite dienen.
K-Object.xsp
K-Object-Edit.xsp
K-Object-Response.xsp
K-Object-
NewComments.xsp
KPool_Start.xsp
KPoolLayout Stellt ein Template für Web-Frontend dar.
Importiert CSS-Resource GCC_Style.css
KPool_Start.xsp
ErrorPage.xsp
Navi_Menu Nutzt Websetting-Dokument als Datenquelle
um die Links anzuzeigen.
Bietet Login-Funktionalität, sowie die Steue-
rung der Anzeige des Dok-Headers.
KPool_Start.xsp
IV. Übersicht der erstellten Views
Notes-View Verwendet in
GCC_xpThemesIndex
GCC_xpKeywordsIndex
GCC_xpMetaStructuresIndex
Werden für die Erstellung der Kategorienliste
verwendet.
GCC_xpThemes
GCC_xpKeywords
GCC_xpMetaStructures
Dienen als Datenquelle des View-Controls in
View_Navigation.xsp
47 Anhang
V. Übersicht der Funktionen in (xpGCC_View_Body.jss) ScriptLibrary
Funktion Beschreibung
ariadnePath() Anhand der URL-Parameter (View, Kategorie und Ebene) wird
Ariadne Pfad mit Hyperlinks zur Navigation gebildet und ange-
zeigt. Wenn URL-Parameter leer ist, werden Themes angezeigt
classList() Berechnet die Liste in Abhängigkeit der gewählten Kategorien
und Ebene. Anhand der URL-Parameter wird die richtige View
zum auslesen der Werte genommen und mittels String bzw. Lis-
ten-Operationen werden die Kategorien zusammengestellt und als
Hyperlinks angezeigt.
viewTitle() Bildet die Anzeige der Subject, Themes, Meta Structures und
additional Thumbnails in den View-Einträgen, nutzt die unten
beschriebenen Funktionen.
viewThemes() Zur formatierten Anzeige der Themes-Kategorien im Dokumen-
tenkopf und in den View-Einträgen. Wie auch bei vorhandenen
Views des K-Pools, werden die * bei Themes ausgeschnitten.
viewMetaStructures() Zur formatierten Anzeige der Meta Structures im Dokumenten-
kopf und in den View-Einträgen. Wie auch bei den vorhande-
nen Views des K-Pools, werden die Meta Structures, welche mit
einem * beginnen, bei der Darstellung im Web verborgen.
viewTaxonomy() Zur formatierten Anzeige der Keywords im Dokumentenkopf und
in den View-Einträgen.
viewAttachments() Zur Anzeige der „additional Thumbnails“ in dem Dokumenten-
kopf und in den View-Einträgen.
VI. Übersicht der Funktionen in (xpGCC_ServerSide.jss) ScriptLibrary
Funktion Beschreibung
initApplication() Initialisiert einige globale Scope-Variablen für KPool_Start.xsp
docResp() Rekursive Funktion zur Anzeige der hierarchischen Liste. Anhand
der Response-Collection werden alle Ebenen der Kommentare
berechnet und entsprechend eingerückt angezeigt. Hierbei werden
die Web-Settings des Dokumenten berücksichtigt (z.B. ob die
Liste mit oder ohne Hyperlinks angezeigt werden darf, bzw. ob
die Liste verborgen werden soll.
48 Anhang
VII. Ergänzungen und Hinweise zu der Realisierung
Wie in der Beschreibung der Umsetzung erwähnt, wurde versucht, eine Arbeitsbasis für
die Analysen und Konzeption der Realisierung zu schaffen. Da das eigentliche Ziel war,
die Nutzenpotenziale der XPages zu analysieren, wurde darauf geachtet in erster Linie die
Funktionalitäten der XPages zu nutzen und nicht zusätzliche Features einzubringen. Die
Gestaltung eines neuen Layouts für den K-Pool wurde nicht als primäres Ziel angesehen,
demnach wurde das Aussehen des aktuellen Web-Frontends weitgehend nachgebildet.
Hinweise zum Login:
Falls die Datenbank lokal getestet werden soll, sollte beachtet werden, dass der Lo-
kalserver keine Anmeldung unterstützt, so dass keine neuen Dokumen-
te/Kommentare erstellt bzw. bearbeitet werden dürfen.
Folgende Abbildung veranschaulicht die Verwendung der oben beschriebenen Funktionen
bei der Darstellung des Web-Frontends.
Hinweise zur classList()-Funktion:
classList() wurde als eine „Umweg“ Lösung zu dem Problem der Kategorienfilterung
entwickelt. Die Funktion bildet die Kategorien ohne Begrenzung der Anzahl von angezeig-
ten Werten auf einer Seite ab und kann sehr lang werden. Aus dem Grund wäre diese nicht
für den Einsatz in einem operativen DMS geeignet und sollte mit einem „Pager“ zum Um-
bruch der Angezeigten Ergebnisliste erweitert werden.
Aus Websettings-
Dokument
Content_Search (Typeahead)
ariadnePath()
classList()
viewTitle() viewTaxonomy()
49 Anhang
K-Object-Edit.xsp - Formular zum Erstellen bzw. Bearbeiten der Dokumente.
Hinweise zu dem RichText-Editor in XPages:
Es wurde beobachtet, wenn das RichText-Feld (z.B. BodyWWW) beim Speichern
des Dokuments leergelassen wurde, wird vom System ein Text-String (Content-
Type: text/html; charset="utf-8") in das Feld geschrieben. Des Weiteren scheint das
Rendern der Notes-Tabbed Tables in dem RichText-Feld fehlerhaft zu sein, da die
Darstellung dieser Tabellen nicht aufrechterhalten wird: sie werden nicht mehr als
Register, sondern „flach“ angezeigt.
Hinweise zu Thumbnails in XPages:
Import/Export der Thumbnails wurde mit FileUpload/FileDownload Controls reali-
siert. Beim Speichern des Dokuments wird der Wert des ImageFileName-Items ge-
setzt, anhand dieses Namens kann das Attachment im Web als ein Bild angezeigt
werden. Mit dem Ziel das mehrfache Hinzufügen der Bilder zu vermeiden, wird
FileUpload Control ausgeblendet, so dass ein neues Bild erst nach dem Entfernen
des vorhandenen zugegeben werden darf.
Hinweise zu WebSettings in Metadaten:
Folgende Subforms wurden mit einem Feld „allowWebEditing“ erweitert, um die Be-
arbeitung im Web verbieten zu können: GCC_NC_LTT_K-Object, GCC_NC_LTT_K-
Literature, GCC_NC_LTT_K-Standard.
FileUpload im Repeat Control
50 Anhang
K-Object.xsp Präsentation der Dokumente
K-Object-NewComment.xsp Verfassen der Kommentare
docResp()
viewThemes()
viewMetaStructures()
viewTaxonomy()
viewAttachments()
51 Eidesstattliche Erklärung
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit selbstständig und unter
Verwendung der angegebenen Hilfsmittel angefertigt habe; die aus fremden Quellen direkt
oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht
veröffentlicht.
Paderborn, den …………………. …………………………………………
(Datum) (Unterschrift)