Bachelorarbeit - Groupware Competence Center

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

file:///E:\UNI\BA\BA.9.docx%23_Toc221528573

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


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.


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.)


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.


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.


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 )


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]

http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html


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)

http://www.flickr.com/photos/tags

http://upload.wikimedia.org/wikipedia/commons/d/d8/TagCloudBasedOnFlickr.png


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).


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)


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


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)


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).


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]

http://dojotoolkit.org/


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]

http://www-10.lotus.com/ldd/ddwiki.nsf/dx/UsingLocalizationOptions.htm

http://www-10.lotus.com/ldd/ddwiki.nsf/dx/error-management-in-xpages.htm


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).


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


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.



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.


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.


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

http://gcc.upb.de/www/WI/WI2/wi2_lit.nsf/KPoolPage?OpenForm&view=KPoolThemes&category=ACTIVITY%20MANAGER


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

http://gcc.upb.de/www/WI/WI2/wi2_lit.nsf/KPoolThemes/6C34D9C613D61673C125748100415110?OpenDocument


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.


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.


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.


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.


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


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.


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.


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.


- 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:


- 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.


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.


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


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


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-


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.



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.


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


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.


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


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


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-


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

http://gcc.uni-paderborn.de/www/WI/WI2/wi2_lit.nsf/KPoolThemes/76681D46C83A8%20E9CC12571950077CDF4?OpenDocument

http://gcc.uni-paderborn.de/www/WI/WI2/wi2_lit.nsf/KPoolThemes/76681D46C83A8%20E9CC12571950077CDF4?OpenDocument

http://www-10.lotus.com/ldd/nd85forum.nsf/0/0efc82dac98270ff852574580060a1ba/

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

http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp

http://www-10.lotus.com/ldd/ddwiki.nsf/dx/11192008104656AMAAKLHL.htm

http://www-10.lotus.com/ldd/ddwiki.nsf/dx/10082008104832AMDOCKD8.htm

http://www.thenorth.com/northern.nsf/html/XpagesArticle

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





AcknowledgementUILib (OpenDialogReceipt)

wfUIDocument (OpenStartDialog)

wfUIDocument (OpenSettingsDialog )

wfUIDialogSetting (ClickButtonReleaseDoc )

wfUIDialogSetting (Call ClickButtonReserveDoc)

wfUIDialogSetting (OpenWFSettingDialogForm)

wfUIDocument (OpenAdHocDefDialog)

wfUIDocument (OpenExceptionsDialog )

wfUIDocument (OpenLogDialog)


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


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-

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)

Bachelorarbeit - Groupware Competence Center

Documents

Transcript of Bachelorarbeit - Groupware Competence Center