Erweiterung eines Content Managemant Systems um die ... · Ziel dieser Arbeit ist die Erweiterung...

Universitat HannoverFachgebiet Datenbanksysteme

Institut fur InformationssystemeFachbereich Informatik

Bachelorarbeit

im Studiengang Angewandte Informatik

Erweiterung eines Content-Management-Systemsum die Erzeugung und Konfiguration

von Datenbankbrowsern

27. September 2004

Daniel PlappertMatr.-Nr. 1937457

Prufer: Prof. Dr. Udo LipeckZweitprufer: Dr. Hans Hermann Bruggemann

Betreuer: Prof. Dr. Udo Lipeck

Erklarung

Hiermit versichere ich, Daniel Plappert, die vorliegende Bachelorarbeit ohne fremdeHilfe und nur unter Verwendung der von mir aufgefuhrten Quellen und Hilfsmittelangefertigt zu haben.

Hannover, den 27. September 2004

Danksagung

An dieser Stelle mochte ich die Gelegenheit nutzen, um mich bei denen zu bedanken,die mich bei der Entstehung dieser Arbeit unterstutzt haben.

Besonderer Dank gilt Herrn Prof. Dr. Lipeck fur die Betreuung wahrend dieser Ar-beit. Ihm verdanke ich viele Stunden der kreativen Diskussion. Dabei mochte ichbesonders seine Anregungen, Hinweise und Anderungsvorschlage wahrend der Ge-sprache hervorheben.

Desweiteren mochte ich mich bei Dipl.-Math. Mazeyar E. Makoui, Dipl.-Math. Sa-scha Klopp und Dipl.-Math. Michael Tiedge bedanken, die mir bei Fragen helfendzur Seite standen.

Schließlich mochte ich mich noch bei meinen Eltern und meiner Schwester bedanken,die mich in allem unterstutzt haben.

Hannover, den 27. September 2004

Zusammenfassung

Ziel dieser Arbeit ist die Erweiterung des Content-Management-Systems TYPO3um ein Programmpaket zur Erzeugung von Datenbankbrowsern.

Ein Datenbankbrowser ist eine Zusammenstellung von einer oder mehreren Ausga-bemasken, die in einer festgelegten Beziehung zueinander stehen. Die Aufgabe derMasken besteht darin, auf der Webseite Tupelinformationen einer oder mehrerer Re-lationen darzustellen. Durch Verweise der Masken kann der Besucher der Webseitevon den Informationen einer Maske zu denen einer anderen gelangen.

Die Integration des Programmpakets in das Content-Management-System TYPO3bietet dem Anwender die Moglichkeit, die Datenbankbrowser dort zu erstellen, zuverwalten und in Webseiten einzubinden.

Inhaltsverzeichnis

1 Einleitung 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Grundlagen 3

2.1 Content-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Content-Management-Systeme . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 Templatekonzept . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.2 Kategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 TYPO3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.2 Extension Manager . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.3 Datenbankstruktur . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Konzepte 11

3.1 Allgemeine Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Datenbankbrowser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 Masken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.4 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.5 Masken verknupfen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.6 Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.7 Ausgabelayout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.8 Unabhangigkeit vom CMS . . . . . . . . . . . . . . . . . . . . . . . . 20

3.9 Zu speichernde Informationen . . . . . . . . . . . . . . . . . . . . . . 21

3.10 Verwendung mehrerer Datenbanksysteme . . . . . . . . . . . . . . . . 22

4 Benutzerhandbuch 25

4.1 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 DBBrowser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3 Die Benutzung des Editors . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3.1 Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3.2 Einen neuen DBBrowser erstellen . . . . . . . . . . . . . . . . 27

4.3.3 DBBrowser editieren . . . . . . . . . . . . . . . . . . . . . . . 48

4.4 Content-Element: DBBrowser . . . . . . . . . . . . . . . . . . . . . . 49

5 Implementierung 555.1 Struktur des Data-Dictionarys . . . . . . . . . . . . . . . . . . . . . . 555.2 Die PHP-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.2.1 DBBrowserEditor . . . . . . . . . . . . . . . . . . . . . . . . . 565.2.2 DBBrowser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.2.3 Mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.2.4 DBResult . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.2.5 DBAttributeContainer . . . . . . . . . . . . . . . . . . . . . . 575.2.6 DBAttribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.2.7 DBDataType . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.2.8 Searchbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.2.9 SearchItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.2.10 LayoutManager . . . . . . . . . . . . . . . . . . . . . . . . . . 585.2.11 MaskLayout . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.2.12 HTMLFormElement . . . . . . . . . . . . . . . . . . . . . . . 585.2.13 DBRelation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.2.14 DBColumn . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2.15 ForeignKeyObject . . . . . . . . . . . . . . . . . . . . . . . . . 595.2.16 ForeignKeyHandler . . . . . . . . . . . . . . . . . . . . . . . . 595.2.17 DBAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2.18 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.3 Programmpaket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.3.1 Der Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.3.2 Der Interpreter . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.4 Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.4.1 Masken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.4.2 Ausgabelayout . . . . . . . . . . . . . . . . . . . . . . . . . . 645.4.3 Attribute und Datentypen . . . . . . . . . . . . . . . . . . . . 655.4.4 Suchfelder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.5 Integration in TYPO3 . . . . . . . . . . . . . . . . . . . . . . . . . . 665.5.1 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . 665.5.2 Erstellen des Moduls und Plugins . . . . . . . . . . . . . . . . 665.5.3 Erweiterung des Moduls . . . . . . . . . . . . . . . . . . . . . 695.5.4 Erweiterung des Plugins . . . . . . . . . . . . . . . . . . . . . 71

5.6 Einschrankungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6 Erweiterungsmoglichkeiten 736.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.2 Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.2.1 Neue Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . 756.2.2 Hinzufugen von weiteren Methoden . . . . . . . . . . . . . . . 76

6.3 Erstellen neuer Ausgabelayouts . . . . . . . . . . . . . . . . . . . . . 786.4 Suchfelder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.5 Verwendung anderer DBMS . . . . . . . . . . . . . . . . . . . . . . . 86

A Installation 89

Kapitel 1

Einleitung

1.1 Motivation

Die Verwendung von Content-Management-Systemen (CMS) vereinfacht die Ver-waltung von Webseiten und deren Inhalten (Content) erheblich. Durch den Einsatzvon CMS werden die eingegebenen Texte in der gewunschten Art und Weise zudefinierten Zeitpunkten publiziert.

Ein Problem entsteht, wenn von einem CMS auf ein anderes umgestellt werdensoll. Ein ahnliches Problem ergibt sich, wenn nach Jahren (ohne vorherige Verwen-dung eines CMS) bereits eine Fulle von Daten vorhanden sind, die sich nicht ohneweiteres in das neu erworbene CMS integrieren lassen. Die bereits vorhandenenDaten konnen auf einem Datenbankentwurf basieren, in dem durch FremdschlusselBeziehungen zwischen Relationen festgelegt sind. Die Erhaltung dieser Beziehungenin einem CMS ist selten gegeben, zumal kostengunstige oder Open Source CMS inden haufigsten Fallen nur MySQL1 verwenden und die Verwendung von anderenDatenbanken nicht anbieten. Um dennoch eine Ausgabe erhalten zu konnen, gibt esverschiedene Losungen:

• durch aufwendige Konvertierungen kann man zu versuchen die vorhandenenDaten in das CMS zu integrieren. Bei einer eigenen Datenbankstruktur ist diesaber in den seltensten Fallen moglich.

• es konnen Ausgabeskripte erstellt werden, die die Daten in der gewunschtenForm aus der Datenbank ausgeben. Das Erstellen dieser Skripte ist aufwendig,und Anderungen an der Ausgabe konnen nicht uber das CMS vorgenommenwerden, sondern mussen in dem jeweiligen Skript (per Hand) vorgenommenwerden.

Es ware daher sinnvoll Ausgabeskripte zu erstellen, die auch die Beziehungenzwischen den Relationen beachten, d.h. es konnte z.B. moglich sein von einer Listevon Filmen auf die im Film mitspielenden Schauspieler zu verweisen. Es ware auchdenkbar, die auszugebenden Informationen aus verschiedenen Relationen auf einer

1MySQL unterstutzt in der derzeitigen Version 4.20 nur im Tabellentyp InnoDB Fremdschlussel

Webseite zusammen auszugegeben. Die Verknupfung von Relationen ist daher eben-falls ein wichtiger Punkt beim Erstellen von Ausgaben. Wie aber bereits erwahntbietet das Erstellen von Ausgabeskripten einige Nachteile.

Um diesem Problem zu begegnen bietet es sich an, mit Hilfe einer Erweiterungdes CMS Ausgaben erstellen zu lassen, die gewollte Beziehungen zwischen Relationenerkennt und, sofern dies gewunscht wird, Ausgaben auch fur die an der Beziehungteilnehmenden Relationen erstellt. Auf diese Art und Weise ware ein Browsen durchdie Datenbank auf der Webseite moglich. Fur eine gemeinsame Datenausgabe ausmehreren Relationen auf einer Webseite sollte eine Moglichkeit vorgesehen werden,Relationen unkompliziert verknupfen zu konnen. Um diese Ausgaben beeinflussenzu konnen, musste dieser Browser konfigurierbar sein. Das Erstellen aufwendigerSkripte wurde somit entfallen und die Steuerung der Ausgabe ware uber das CMSmoglich und nicht durch ein Editieren der Ausgabeskripte. Eine Anbindung an dieWebseiten ware somit ebenfalls gewahrleistet.

1.2 Gliederung

Kapitel 2 gibt eine Einfuhrung in Content-Management-Systeme (CMS). WichtigeBegriffe wie Content, Backend und Frontend werden erklart. Abschließend erfolgt ei-ne kurze Einfuhrung in das CMS TYPO3, in welches das Programmpaket integriertwurde. Dabei werden nur die Aspekte besprochen, die fur diese Arbeit relevant sind.

Konzepte werden in Kapitel 3 beschrieben. Es wird geklart, was Masken sind undwie sie verknupft werden konnen, um so ein Netzwerk aufzubauen und ein Browsenzu ermoglichen.

Kapitel 4 ist das Benutzerhandbuch fur das entwickelte Programmpaket. Auch wirdgezeigt, wie die erstellten Datenbankbrowser mit Webseiten in TYPO3 verknupftwerden konnen.

Kapitel 5 beschreibt schließlich die Implementierung des Programmpakets. Das Ka-pitel beinhaltet eine Auflistung aller entwickelten PHP-Klassen und zeigt außerdemdie Integration in TYPO3.

Erweiterungsmoglichenkeiten schildert Kapitel 6. Das Kapitel zeigt an Beispielen,in wieweit sich die Applikation erweitern lasst und vermittelt zudem einen tieferenEinblick in die Implementierung.

Kapitel 2

Grundlagen

Bevor auf die Losungsansatze eingegangen werden kann, muss die Bedeutung vonwichtigen Begriffen geklart werden. Zuerst wird eine kurze Einfuhrung in die Ar-beitsweise von Content-Management-Systemen (CMS) gegeben. Im Anschluß daranwird TYPO3 vorgestellt.

Diese Einfuhrung in TYPO3 erhebt keinen Anspruch auf Vollstandigkeit, sondernerwahnt nur die Dinge, die fur das Verstandnis der weiteren Kapitel notwendig sind.

2.1 Content-Management

Unter dem Begriff Content werden beliebige Inhalte einer Website verstanden. DerBegriff umfasst Beitrage (in Foren, Chats etc.) oder zur Verfugung gestellte In-formationen (z.B. Produkt- oder Unternehmensinformationen). Content setzt sichaus mehreren Content-Elementen zusammen. Ein Content-Element kann eine Uber-schrift, eine Grafik, eine Punktliste, Tabelle o.a. sein.

Die stetige Steigerung des Umfangs dieser Inhalte erfordert neue Konzepte undTools fur deren Verwaltung. Content-Management (CM) beinhaltet die Erfassung,Planung, Steuerung und Kontrolle dieser Inhalte. Die Softwarelosung fur diese Auf-gaben sind Content-Management-Systeme.

2.2 Content-Management-Systeme

Wichtigstes Merkmal von Content-Management-Systemen (CMS) ist die Trennungzwischen dem Inhalt der Webseite (Content) und deren Gestaltung. Es automatisiertden Lebenszyklus von Webinhalten mit dem Ziel einer effizienteren und effektiverenHerstellung, Pflege und Wartung von Webseiten.

Neben den bereits erwahnten Aufgaben werden weitere Anforderungen an einCMS gestellt: Inhalte in mehreren Sprachen darstellen, Verwaltung mehrerer Benut-zer (Redakteure, Designer, Administratoren) mit unterschiedlichen Rechten, Versi-onsverwaltung, Steuerung des Arbeitsprozesses (Workflow) von Dokumenten undIntegration von Fremdanwendungen uber eine Plattform (Portalsysteme).

Der Aufbau eines CMS gliedert sich in die Ebenen Prasentation, Anwendung undDatenbank (s. Abb. 2.1). Eine wichtige Unterscheidung in der Prasentationsebene

Abbildung 2.1: Aufbau eines Content-Management-Systems

sind die zwei Bereiche:

• FrontendDer Frontend-Bereich ist die eigentliche Webprasenz

• BackendDieser Bereich wird auch Administrationsbereich genannt. Die gesamte Ver-waltung der Inhalte wird hier gesteuert. Der Zugang ist nur autorisierten Be-nutzern erlaubt.

Somit stellt sich eine weitere Anforderung an ein CMS. Der Administrations-bereich muss zentral auf einem Server sein. Fur den Zugang zum CMS soll keineweitere Client-Software notig sein, sondern der Zugriff soll direkt uber das Internet(durch einen Browser) erfolgen.

2.2.1 Templatekonzept

Um die Trennung von Inhalt und Gestaltung zu erreichen, werden in den meistenFallen Templates benutzt. Diese sind vordefinierte Designvorlagen fur die Darstel-lung von Inhalten. Ein Template enthalt normalerweise nur den HTML-Code, derallgemein das Layout einer Webseite beschreibt. An bestimmten Stellen in den Tem-plates werden Platzhalter eingebaut, die verschiedene Aktionen auslosen konnen. Beieinfachen CMS wird hier lediglich der konkrete Inhalt eingesetzt, der in dieser Sei-te angezeigt werden soll, z.B. anklickbare Uberschriften aktueller Nachrichten, dieNachrichten selbst usw.. Auf diese Weise konnen Webinhalte ohne jegliche Kennt-nisse von HTML eingegeben und publiziert werden. Diese Aufgabe wird daher meistvon Redakteuren wahrgenommen, die Gestaltung der Templates von Designern.

Wird z.B. das Design einer Webseite geandert, mussen lediglich die entsprechen-den Templates geandert werden. Damit verschiedene Inhalte oder Bereiche der Web-prasenz unterschiedlich dargestellt werden konnen, konnen beliebig viele Templateserstellt werden. Redakteure haben somit spater die Moglichkeit aus einer Vielzahl

Abbildung 2.2: Templatekonzept

von Templates, bzw. grafischen Vorlagen, dem Inhalt ein angemessenes Layout zu-zuweisen.

2.2.2 Kategorien

CMS lassen sich in zwei unterschiedliche Kategorien einteilen:

• Serverseitiges CMSEin serverseitiges CMS braucht eine serverseitige Programmiersprache, diedort meist in Verbindung mit einer Datenbank steht, welche die Daten direktauf dem Server verwaltet. Dadurch konnen Daten weltweit - meist nur mitHilfe eines Browsers - uber das Internet verwaltet werden. Mehrere Nutzerkonnen so eine Webseite verwalten. Viele serverseitige CMS erlauben Berech-tigungen nach Benutzern zu differenzieren. Serverseitige CMS sind fur kleinebis hin zu sehr großen Webauftritten geeignet.

• Clientseitiges CMSClientseitige CMS werden meist mit Hilfe eines Programms gesteuert. DieDaten werden dann (z.B. mittels FTP) auf den Server hochgeladen. Deswegenist keine serverseitige Programmiersprache notig. Dadurch muss immer vondiesem Rechner die Webseite verwaltet werden. Diese Variante ist fur kleineWebauftritte mit nur einem Redakteur zu empfehlen.

Zurzeit gibt es eine ganze Reihe von CMS. Bekannte Open Source CMS sinddas hier vorgestellte TYPO3, OpenCMS, Contenido oder das CMS von eZpublish.Diese CMS unterscheiden sich deutlich in der Funktionalitat. Das wohl bekanntesteist TYPO3. Weit verbreitete kommerzielle CMS sind die gleichnamigen CMS derFirma RedDot Solutions und Imperia AG. Sie unterscheiden sich von Open SourceCMS im Service und Erscheinungsbild. Deutliche Unterschiede in der Funktiona-litat gibt es im Bereich Workflow. Dieser ist bei den kommerziellen Produkten sehrviel umfangreicher und bietet gerade fur große Firmen wesentlich mehr Funktionen.

Viel Wert wird ebenfalls auf die Verfugbarkeit von Dokumenten in verschiedenenSprachen gelegt. Dieser Punkt ist in Open Source CMS selten umgesetzt.

2.3 TYPO3

TYPO3 ist ein Open Source Content-Management-System fur kleine bis mittelgroßeUnternehmen. Entwickelt wurde es von dem Schweden Kasper Skarhøj. Als server-seitiges plattformunabhangiges CMS kann TYPO3 mit nahezu jedem verfugbarenBrowser bedient werden.

2.3.1 Architektur

Im Administrationsbereich (Backend) von TYPO3 erstellt und verwaltet der Be-nutzer die Content-Elemente, sowie die dazugehorigen Webseiten, auf denen dieContent-Elemente angezeigt werden. Es lassen sich alle Einstellungen vornehmen,die Anderungen an der Webprasenz (Frontend) betreffen. Sei es eine Anderung amTemplate, das Erstellen neuer Webseiten oder die Verwaltung der Content-Elemente.

TYPO3 ist fast uneingeschrankt erweiterbar. Die Funktionalitat kann durch so-genannte Extensions verbessert werden. Mit Hilfe der Extensions lassen sich z.B.neue Content-Elemente erstellen, die in die Webseite eingebunden werden konnen.Der Begriff Extension umfaßt in TYPO3 die Begriffe Plugin und Modul.

Module sind Erweiterungen des Backend, die ihren eigenen Platz im Admini-strationsmenu besitzen. Es werden zwei Arten von Modulen unterschieden: Main-Module und Sub-Module. Diese Unterscheidung dient nur dazu, Gruppen von ge-meinsamen Modulen zu bilden. So umfaßt das Modul Web (fur die Verwaltung derWebseiten und deren Content-Elemente zustandig) die Sub-Module

• PageErstellen und Verwalten von Webseiten

• ViewDient zum Betrachten der Webseiten (Preview)

• ListAuflisten der erstellten Content-Elemente auf einer Webseite

• InfoInformationen uber Webseiten, wie z.B. das Erstelldatum, Autor usw.

• AccessZugriffsrechtevergabe von Webseiten

• FunctionsBietet einige Hilfsfunktionen, wie das gleichzeitige Erstellen mehrerer Websei-ten

• TemplateTemplateverwaltung

Alle diese Module befassen sich mit der Verwaltung von Webseiten-Informationen.Module sind also Applikationen innerhalb des CMS, die die Moglichkeiten des CMSerweitern. Module sind nicht fur die Ausgabe von Daten auf einer Webseite zustandig.

Ein Plugin spielt eine wichtige Rolle auf der Webprasenz. Der Begriff Plugin istan dieser Stelle etwas verwirrend, da er sowohl eine Erweiterung des Frontend, alsauch ein Content-Element Typ in TYPO3 bezeichnet. Besser geeignet ware auchhier die Bezeichnung Modul, doch da der Begriff bereits fur eine Erweiterung desBackend benutzt wird, entschied sich der Entwickler fur die Bezeichnung Plugin. ImFrontend ist mit Plugin eine Applikation gemeint, die die Ausgabe von Daten regeltoder Daten sammelt. In TYPO3 sind verschiedene Arten von Plugins erstellbar:

• Plugin in der Liste der Content-ElementeDer Plugin steuert die Ausgabe des Contents. Im Backend (und bei Bedarfauch im Frontend) kann das Plugin alle gewunschten Daten erfassen und diesedann ausgeben. Beispiele hierfur sind Foren oder Gastebucher.

• Textbox-TypDieser Plugin hat nur Einfluss auf Content-Elemente vom Typ Textbox.

• Menu/Sitemap-ItemFugt den Plugin zur Liste der Sitemaps hinzu, d.h. wenn eine Liste mit Linksauf andere Seiten oder Content-Elemente ausgegeben werden soll oder abereine alternative Sitemap.

• eigenstandiges Content-ElementErweitert die Liste der Content-Elemente. Wenn etwas anderes als z.B. einePunktliste gewunscht wird oder es moglich sein soll, komplexere Tabellen zuerstellen.

• neuer Header-TypUm Uberschriften in einem anderen Design (Font, Schriftgroße etc.) ausgebenzu konnen.

• benutzerdefinierter TagWenn der Plugin in den Textfeldern der Content-Elemente nach benutzerdefi-nierten Tags suchen soll. Zum Beispiel:

<meinTag>dies ist der Inhalt</meinTag>

Der Inhalt dieses Tags steht dann zur Bearbeitung durch den Plugin bereit.

• eingebundene BibliothekIn diesem Fall wird dieser Plugin eingebunden, wenn die Webseite erstellt wird.

Je nach gestellter Anforderung an den Plugin lassen sich so die passenden Ein-bindungstypen in TYPO3 finden.

Abbildung 2.3: Architektur von TYPO3 (Quelle: www.typo3.org)

Extensions setzen auf der TYPO3 Extension API auf (s. Abb. 2.3). Diese Ex-tension API bildet, wie der Name schon andeutet, eine Schnittstelle zwischen demKern (Core) von TYPO3 und der eigentlichen Extension. Der Kern wird von derTYPO3 Core-Group weiterentwickelt und sollte daher nicht geandert werden. Durchdie Einfuhrung der Extension API ist es moglich TYPO3 zu aktualisieren, ohne dieselbst entwickelten Extensions unbrauchbar zu machen oder deren Funktionsweisezu beeintrachtigen.

2.3.2 Extension Manager

Erweiterungen (Extensions) werden von dem Extension Manager im Backend ver-waltet. Er bietet eine Ubersicht uber alle installierten Extensions, die an dieserStelle auch deaktiviert oder sogar entfernt werden konnen. Weiterhin bietet er dieMoglichkeit, sich Extensions aus dem TYPO3-Repository herunterzuladen oder abermit Hilfe des Kickstart-Wizard (auch Kickstarter genannt) eine eigene Extension zuerstellen.

2.3.3 Datenbankstruktur

Alle vom CMS erfassten Daten (Benutzer, Content-Elemente usw.) werden in einerDatenbank in den entsprechenden Relationen gespeichert. So werden die angeleg-ten Seiten des Webauftritts in der Relation pages gespeichert und die Benutzer desCMS in der Relation be users und be groups (das “be“ steht hierbei fur Backend).Im Zusammenhang mit dieser Arbeit ist nur die Relation tt content wichtig, diealle Informationen zu Content-Elementen speichert, wie z.B. Content-Typ, Publi-zierdatum, Inhalt des Content-Elements, Erstelldatum, Publizierfreigabe usw.. ImKapitel Implementierung wird diese Relation erweitert, damit die Speicherung derausgewahlten Datenbankbrowser moglich ist.

Kapitel 3

Konzepte

Wunschenswert ist das einfache Erstellen von Ausgaben auf einer Webseite. EinBrowsen durch die Datenbank soll sich zudem moglichst leicht und flexibel furden Anwender gestalten. Die Ausgabe muss in vielerlei Hinsicht beeinflusst werdenkonnen, d.h. es soll moglich sein, z.B. die auszugebenden Attribute auszuwahlen,eMail-Adressen als klickbare HTML-Links darstellen zu konnen oder die Sortie-rungsreihenfolge festzulegen. Die erstellten Datenbankbrowser sollen, wie andereContent-Elemente, ebenfalls in Seiten integriert werden konnen. Die dazu entwickel-ten Konzepte sind Gegenstand dieses Kapitels.

3.1 Allgemeine Konzepte

Das Erstellen von neuen Datenbankbrowsern (DBBrowser), sowie das Einbindenin Webseiten kann nur im Backend (Administrationsbereich) des CMS erfolgen.Der DBBrowser wird daher sowohl vom Backend als auch vom Frontend (fur dieAusgabe) benotigt. Diese Aufteilung macht deutlich, dass die Applikation aus zweiTeilen bestehen muss:

• EditorEr wird zum Erstellen und Bearbeiten der DBBrowser benotigt. Fur jedenDBBrowser erstellt der Editor eine Parameterdatei. Daher wird der Editor imBackend des CMS eingesetzt.

• InterpreterDie erstellten Parameterdateien werden vom Interpreter eingelesen und dieAusgaben entsprechend der Konfiguration generiert. Anschließend wird dieerstellte Ausgabe an das CMS weitergegeben. Dieser Teil kommt im Frontenddes CMS zum Einsatz.

3.2 Datenbankbrowser

Zentraler Bestandteil des Datenbankbrowsers sind die Ausgabemasken (kurz: Mas-ken). Masken dienen dazu, Tupelinformationen auf der Webseite auszugeben. Jeder

Datenbankbrowser besteht aus einer oder mehreren Masken, die durch eine Ver-bundbedingung miteinander verknupft sein konnen und somit ein Netzwerk bilden(Prinzip s. Abb. 3.1). Auf diese Weise wird ein Browsen ermoglicht. Einstiegspunktin dieses Netzwerk bildet immer die Hauptmaske. Diese wird angezeigt, wenn dieWebseite aufgerufen wird, in die der DBBrowser integriert wurde.

Abbildung 3.1: DBBrowser-Prinzip

3.3 Masken

Mit Hilfe einer Maske werden die Tupelinformationen der ausgewahlten Attributeder Datenbank ausgelesen und in der gewunschten Art und Weise auf der Webseitepubliziert. Abbildung 3.2 zeigt das ER-Modell des DBBrowsers. Masken bestehenaus einer oder mehreren verknupften Relationen und den verwendeten Attributen.Fur eine Maske kann zusatzlich eine Suche angeboten werden, und auch das Aus-gabelayout, das die Ausgabe der Tupelinformationen steuert, ist Bestandteil derMaske. Weiterhin ist eine Verknupfung mit anderen Masken moglich.

Das Erstellen eines DBBrowsers beginnt immer mit dem Anlegen der Hauptmas-ke. Fur die Hauptmaske (und auch fur alle anderen Masken) muss eine Startrelationgewahlt werden. Dafur mussen durch den Editor alle Relationen ausgelesen werden,auf denen der Benutzer (des Datenbank-Accounts) Leserechte besitzt.

Zur Auswahl der Startrelation stehen sowohl Tabellen, als auch Sichten. EineStartrelation muss gewahlt werden, da Informationen nur aus einer Relation stam-men konnen. Eine Maske muss mindestens eine Relation beinhalten und dies ist dieStartrelation. Diese kann spater mit anderen Relationen verknupft werden.

Wurde eine Startrelation gewahlt, mussen alle Attribute dieser Relation undeventuell vorhandene Fremdschlusselinformationen ausgelesen werden. Zu beachtenist, dass die Fremdschlusselinformationen in beide Richtungen gehen konnen, einAttribut der Relation daher referenziert werden kann (von einem Attribut einer an-deren Relation) oder selbst als Fremdschlussel dient. Diese Informationen werdenaus dem Data-Dictionary des Datenbank-Management-Systems (DBMS) ausge-lesen und mussen gespeichert werden, damit es dem Benutzer ermoglicht werden

Abbildung 3.2: ER-Modell des DBBrowsers

kann, einfach weitere Relationen uber Fremdschlusselbeziehungen in seine Ausgabeeinbinden zu konnen.

Das Einbinden anderer Relationen kann nicht nur uber Fremdschlusselbeziehun-gen erfolgen, sondern kann auch durch andere Verbundbedingungen erfolgen. Dahermuss dem Benutzer die Moglichkeit gegeben werden, Verbundbedingungen mit an-deren Relationen auswahlen zu konnen. Moglich ist auch der eventuelle Selbstbezugeiner Relation. Als Beispiel sei folgende Relation gegeben:

EMP(EmpNo, Name, Sal, Tax, MgrNo → EMP, DeptNo → Dept)

Zu sehen ist hier der Selbstbezug durch MgrNo → EMP. Um Informationender Mitarbeiter und deren Vorgesetzten zu erhalten, darf daher ein Einbinden derselben Relation nicht unterbunden werden. Fur ein mehrfaches Einbinden der selbenRelation ist die Vergabe von Aliasnamen notwendig. Ohne diese Vergabe ware nichteindeutig, auf welches Attribut sich die Anfrage bezieht. Der SQL-Parser wurdediese Anfrage mit einer Fehlermeldung quittieren:

SELECT EMP.Name FROM EMP, EMP WHERE EMP.EmpNo = EMP.MgrNo

Mit der Vergabe der Aliasnamen konnte die Anfrage korrekt lauten:

SELECT Emp.Name FROM EMP Emp, EMP Emp2 WHERE Emp.EmpNo = Emp2.MgrNo

Fur jede Maske wird eine SQL-Anfrage erstellt und in der Parameterdatei desDBBrowsers gespeichert. Die SQL-Anfrage ergibt sich aus den eingebundenen Re-lationen und den gewahlten Attributen.

3.4 Attribute

Die Tupelinformationen stellen den auszugebenden Inhalt der Masken dar und/oderdienen als Parameter fur Masken. Tupelinformationen von Attributen werden nichtimmer in der Form benotigt, in der sie aus der Datenbank ausgelesen werden. Bspw.kann es sein, dass Berechnungen durchgefuhrt oder Datumsinformationen formatiertausgegeben werden sollen. Dies macht es erforderlich, Attributen Methoden zu zu-weisen, die das Gewunschte leisten. In dem genannten Beispiel musste es durch eineMethode moglich sein, mit dem Tupelwert eine Berechnung durchzufuhren und miteiner weiteren Methode musste das Datum formatiert werden konnen.

Jedes Attribut besitzt einen Datentyp, der fur das Attribut in der Datenbankfestgelegt ist und daher nur bestimmte Operationen zulasst. So kann mit einemAttribut von Typ Date nicht die gleiche Berechnung durchgefuhrt werden, wie miteinem Attribut vom Typ Number. Ein Beispiel: das Attribut einstell datum derRelation EMPLOYEE habe den Datentyp Date. Die Anfrage

SELECT einstell_datum * 5 FROM EMPLOYEE

wurde diese Fehlermeldung zur Folge haben: “inconsistent datatypes: expectedNUMBER got DATE“.

Dies macht deutlich, dass dem Editor bekannt sein muss, welchen Datentyp dasAttribut hat, damit auf Tupelwerte dieses Datentyps auch die entsprechenden Me-thoden angewendet werden konnen. Der Editor muss also wissen, wie er die Tupel-werte des Attributs zu interpretieren hat und bietet dementsprechende Methodenan, die auf die Tupelwerte angewendet werden konnen. Diese, durch den Editorangebotenen, Methoden sollten auch jederzeit erweitert werden konnen.

Nun konnen sich aber Berechnungen nicht nur auf ein Attribut beziehen, son-dern es konnte bspw. auch die Summe mehrere Attribute gebildet werden. Damitdies moglich ist, mussen alle Attribute zentral verwaltet werden, durch eine extraContainer-Klasse. Durch diese zentrale Verwaltung kann ein Attribut auch auf an-dere Attribute zugreifen. Das entsprechende ER-Modell zeigt Abbildung 3.3. Durchden Zugriff auf die anderen Attribute konnen sowohl deren Namen, als auch derenTupelwerte abgefragt werden.

Abbildung 3.3: ER-Modell der verwendeten Attribute

3.5 Masken verknupfen

Um von der Hauptmaske zu anderen Masken verzweigen zu konnen, muss festgelegtwerden, zu welchen Masken der Besucher der Webseite gelangen kann. Als Beispieldienen die Relationen MOVIE und PLAYS. Fur die Relation MOVIE wurde eineMaske erstellt, die alle Filme ausgibt. Um von den Filmen auf die mitspielendenSchauspieler zu gelangen, muss nun fur die Schauspieler eine weitere Maske erstelltwerden. Damit aber von der Maske der Filme auf die Maske der Schauspieler ver-wiesen werden kann, muss die Verbundbedingung zwischen den Masken festgelegtwerden. Es muss durch eine Verbundbedingung definiert werden, in welcher Bezie-hung die zwei Masken zueinander stehen. Die Maske der Schauspieler muss wissen,

welche Informationen sie anzuzeigen hat, wenn von der Maske der Filme auf sieverwiesen wird.

Damit in der Verbundbedingung eindeutig ist, welches Attribut sich auf die ver-weisende Maske (Quellmaske) und welches sich auf die verwiesende Maske (Zielmas-ke) bezieht, mussen vor den Attributnamen passende Schlusselworter stehen. Wennzu einem Film die Schauspieler angezeigt werden sollen, dann muss der Maske derSchauspieler die ID des Films ubermittelt werden. Die Maske der Schauspieler istsomit die Zielmaske, wahrend die Maske der Filme als Quellmaske dient. Die Ver-bundbedingung zwischen den Masken konnte daher so aussehen:

PLAYS.MOVIE = MOVIE.ID

In dieser Verbundbedingung ist nicht ersichtlich, welches Attribut sich auf dieQuellmaske und welches sich auf die Zielmaske bezieht. Damit dies eindeutig ist,werden passende Schlusselworter benutzt:

destination:PLAYS.MOVIE = source:MOVIE.ID

Das Schlusselwort destination: gibt an, dass sich das folgende Attribut auf dieZielmaske bezieht, entsprechend gibt source: an, dass das nachfolgende Attribut derQuellmaske gehort. Denkbar ist auch eine Ubermittlung von mehr als nur einemParameter. Daher sollte die Verbundbedingung auf mehrere Bedingungen erweiter-bar sein, die durch die logischen Operatoren AND und OR verknupft sind. Damitfehlerhafte Eingaben des Benutzers erkannt werden, muss die Verbundbedingungdurch einen Parser auf Korrektheit gepruft werden und im Fehlerfall eine passendeFehlermeldung ausgeben.

Verbundbedingungen zwischen Masken sollten aber auch durch den Editor auto-matisch erkannt werden. Mit Hilfe von Fremdschlusselbeziehungen der verfugbarenAttribute beider Masken kann eine Beziehung der Masken ermittelt werden. Allevom Benutzer gewahlten Attribute der Quellmaske und alle Attribute der Zielmas-ke eignen sich fur diese Prufung. Die o.g. Verbundbedingung sollte daher schon durchden Editor angezeigt werden, wenn zwischen den beiden Attributen PLAYS.MOVIEund MOVIE.ID eine Fremdschlusselbeziehung existiert.

Nun soll es nicht nur moglich sein, dass die Maske der Schauspieler von der Mas-ke der Filme aufgerufen wird. Denkbar ist ein Netzwerk von Masken, wodurch dieMasken auf mehrere andere Masken verweisen konnen und auf sie selbst von vielenanderen verwiesen wird. Dies macht es notwendig der aufgerufenden Maske mitzutei-len, von welcher Maske auf sie verwiesen wurde. Genauer gesagt muss ihr mitgeteiltwerden, welche Verbundbedingung gelten soll. Die Ubermittlung der Verbundbedin-gung gibt der aufgerufenen Maske weiterhin an, welche Parameter benotigt werden,d.h. welche Parameter sie von der verweisenden Maske bekommt. Denn sollen bspw.die Schauspieler eines Filmes angezeigt werden, dann muss der Maske als Parameterdie ID des Filmes ubermittelt werden.

Beim Aufruf einer Zielmaske muss die Verbundbedingung, die zwischen Quell-und Zielmaske besteht, in die SQL-Anfrage integriert werden. Wird bspw. die IDeines Filmes an die Maske der Schauspieler ubermittelt, dann muss die WHERE-Klausel der SQL-Anfrage der Zielmaske um die Verbundbedingung erweitert werden.

Dies kann wie folgt geschehen: die Zielmaske stellt anhand der Verbundbedingungfest, welche Attribute erforderlich sind. Dazu werden alle Attribute identifiziert,die das vorangestellte Schlusselwort source: besitzen. Anstelle des Schlusselwortesund des Attributnamens wird der ubermittelte Wert eingetragen. Das Schlusselwortdestination: wird entfernt und die Bedingung wird der WHERE-Klausel der SQL-Anfrage hinzugefugt. Als Beispiel sei die bereits oben aufgefuhrte Verbundbedingunggegeben:

destination:PLAYS.MOVIE = source:MOVIE.ID

Von der Quellmaske wird der Parameter MOVIE.ID mit dem Wert 12345 uber-mittelt. Die Zielmaske stellt fest, dass von der Quellmaske ein Parameter MOVIE.IDubermittelt wird und ersetzt das Schlusselwort und den Attributnamen durch dessenWert:

destination:PLAYS.MOVIE = 12345

Anschließend wird das Schlusselwort destination: entfernt und die Bedingung indie WHERE-Klausel eingebunden. Die SQL-Anfrage konnte dann wie folgt lauten:

SELECT PLAYS.PLAYER FROM MOVIEDB.PLAYS WHERE PLAYS.MOVIE = 12345

Da die Ubermittlung von Attributnamen als Parameter Angaben des Architek-turentwurfs der Datenbank preisgibt, sollten anstelle des Attributnamens Zahlenubertragen werden. Die Zahlen entsprechen der Position des Attributs in der Ver-bundbedingung. D.h. das erste Attribut der Quellmaske entspricht einer 1, das zweiteder 2 usw..

Schließlich muss durch den Benutzer des Editors festgelegt werden, wie von einerMaske auf die andere verwiesen werden soll. Ein Verweis ist nur durch einen Linkmoglich, daher muss entweder der Tupelwert eines Attributes als Link dienen oderaber der Benutzer muss die Moglichkeit haben, selbst einen Text fur die Verweiseanlegen zu konnen.

3.6 Suche

Eine Maske kann in einem Teilbereich eine Suchmoglichkeit anbieten. Mit verschiede-nen Suchfeldern wird die Suche in der Ausgabe der Maske ermoglicht. Selectboxen,Eingabefelder oder Checkboxen konnen Suchfelder sein. Durch Selectboxen (auchAuswahlbox) konnen nur bestimmte Werte gewahlt werden, beim Eingabefeld hatder Besucher hingegen die Moglichkeit der freien Eingabe. Checkboxen ermoglichendie Suche nach boolschen Kriterien, wie z.B “nur Filme von diesem Jahr einbezie-hen“.

Eine Suche wird also erst durch Suchfelder moglich. Jedes Suchfeld bezieht sichimmer auf mindestens ein Attribut in der Datenbank. Das eben genannte Beispielder Checkbox (nur Filme dieses Jahres) bezieht sich bspw. auf das Attribut YE-AR der Relation MOVIE. In diesem Fall wird noch ein Kriterium beschrieben: die

Bedingung. Die Tupelwerte des Attributs YEAR mussen gleich dem aktuellen Jahrsein.

Durch den Editor muss es daher moglich sein, neue Suchfelder erstellen zukonnen, z.B. Auswahlboxen. Diese konnen dann mit Attributen aus der Datenbankverknupft werden. Zu den Attributen kann weiterhin eine Bedingung festgelegt wer-den, d.h. soll der Wert des Suchfeldes mit dem Tupelwert ubereinstimmen odersoll der Tupelwert bspw. großer sein. Wurde ein Suchfeld mehreren Attributen zu-geordnet, dann kann schließlich noch entschieden werden, ob diese Bedingung furmindestens ein Attribut oder fur alle gelten soll.

Die Maske muss wissen, wann eine Suche durchzufuhren ist und welche Werte dieSuchfelder haben. Informationen werden auf Webseiten durch Formulare gesammeltund ubertragen. Zustandig fur das Ubertragen dieser Informationen ist der TagFORM im HTML-Code. Dieser gruppiert Formularobjekte, im Fall der Suche dieSuchfelder. Mochte der Besucher der Webseite eine Suche durchfuhren, d.h. er hatdie Suchfelder entsprechend verwendet, muss die Maske feststellen, dass eine Suchemit den Werten der Suchfelder durchzufuhren ist. Dies kann erreicht werden, indembeim Ubertragen der Informationen der Suchfelder noch eine weitere Informationubertragen wird, die die Maske zur Ausfuhrung der Suche veranlasst. Da die MaskeZugriff auf die Suchfelder hat, somit auch auf die Namen der Suchfelder, ist es ihrmoglich, die ubertragenen Informationen zu ermitteln.

Suchfelder beziehen sich durch eine Bedingung auf ein oder mehrere Attributeaus der Datenbank. Diese Bedingung wird dazu verwendet, die WHERE -Klausel derSQL-Anfrage der Maske zu erweitern. Ein Beispiel: es sei angenommen, dass sichein Suchfeld (Textfeld) auf das Attribut TITLE der Relation MOVIE bezieht. AlsBedingung sei die Gleichheit angenommen, d.h. der eingegebene Wert im Textfeldmuss mit dem Wert in der Datenbank ubereinstimmen. Wird durch den Besucherder Webseite in das Suchfeld der Begriff “Shrek“ eingegeben, so wird die Bedingungin die SQL-Anfrage eingebunden, die dann so lauten konnte:

SELECT Movie.TITLE, Movie.YEAR FROM MOVIEDB.MOVIE Movie WHEREMovie.TITLE = ’Shrek’;

Suchfelder mussen sich aber nicht immer nur auf ein Attribut beziehen, sondernkonnen sich auch auf mehrere beziehen. In diesem Fall ist wichtig, in welcher Bezie-hung diese Attribute stehen, d.h. soll der Wert des Suchfeldes sich mindestens aufden Tupelwert eines Attributs beziehen oder auf alle Attribute. Es kann vorkommen,dass die Ubereinstimmung mit einem Attribut ausreicht und eine Ubereinstimmungmit allen Attributen nicht zwingend erforderlich ist.

3.7 Ausgabelayout

Die durch eine Maske erzeugte Ausgabe kann auf vielerlei Arten dargestellt werden.Fur die Darstellung auf einer Webseite ist die Ausgabe in HTML-Tabellen von Vor-teil. Selbst fur die Darstellung in HTML-Tabellen gibt es unzahlige Moglichkeiten,die sich durch die Abmessung der Tabelle, durch Style Sheet Informationen oder dieVerwendung von Grafiken unterscheiden. Diese Prasentation der Daten sollte durchParameter beeinflusst werden konnen.

Abbildung 3.4: Ablauf bei der Anforderung eines Maskeninhaltes

So konnte der Benutzer im Editor festlegen, welche Style Sheets benutzt werdensollen, welche Hintergrundgrafik verwendet wird usw.. Aber trotz der Moglichkeit,durch Parameter die Darstellung zu beeinflussen, so werden auch hierdurch nicht al-le Moglichkeiten abgedeckt. Individuelle Darstellungen sollten aber ebenso moglichsein. Daher ist es notwendig fur die Ausgabe Layouts vorzusehen, die jederzeit er-weitert werden konnen. Jedes Layout kann (sofern der Entwickler/Designer diesvorgesehen hat) durch Parameter beeinflusst werden. Diese Layouts legen schließ-lich fest, wie die Daten auf der Webseite ausgegeben werden. Durch die Verwendungverschiedener Layouts ist die Ausgabe auch nicht auf HTML-Tabellen beschrankt.Ebenso ist eine Ausgabe im XML-Format denkbar.

Dem Ausgabelayout muss die Moglichkeit gegeben werden, auf die Ausgabe Ein-fluss zu nehmen, bevor die durch den Editor erstellte SQL-Anfrage ausgefuhrt wird.Dies kann z.B. notwendig sein, wenn das Layout vorgeben mochte, wie viele Tu-pel ausgelesen werden sollen. Der Benutzer konnte festlegen, dass maximal nur einebestimmte Anzahl von Tupelinformationen ausgegeben werden sollen, damit dieLadezeit der Seite ein bestimmtes Maß nicht uberschreitet. Wurde die Maske alleTupel auslesen, obwohl moglicherweise nur ein kleiner Teil davon ausgegeben werdensoll, ware dies eine Verschwendung an Zeit und Speicher. Aus diesem Grund mussdas Layout vor der Ausfuhrung der SQL-Anfrage die Moglichkeit haben, der Maskebestimmte Einstellungen mitzuteilen.

Abbildung 3.4 verdeutlicht dies. Der Inhalt einer Maske wird angefordert. Vorder Ausfuhrung der SQL-Anfrage wird dem Layout die Moglichkeit gegeben, Einstel-lungen vorzunehmen, bspw. um die maximale Anzahl von Tupeln festzulegen odergar die Anfrage selbst zu andern. Das Andern der SQL-Anfrage ist z.B. erforderlich,wenn dem Besucher der Webseite eine Sortierungsmoglichkeit der Tupel angebo-ten wird. Der Besucher konnte, um die Tupelinformationen zu sortieren, auf einenAttributnamen klicken und so die Sortierung auslosen. Da das Layout Zugriff aufdie SQL-Anfrage hat, kann die Anfrage entsprechend (durch ein Hinzufugen einerpassenden ORDER BY-Klausel) geandert werden. Die Maske fuhrt anschließend dieAnfrage aus und ubergibt die Tupel dabei an das Layout. Nach dem Auslesen wirdder darzustellende Inhalt der Maske vom Layout angefordert und schließlich durchdas CMS ausgegeben. Durch diese einzelnen Phasen hat das Layout die Moglichkeit,die Ausgabe in vielerlei Hinsicht zu andern.

Dem Layout mussen aber auch eine Menge von Informationen bekannt sein oder

Abbildung 3.5: Architektur der Applikation

durch die Maske zur Verfugung gestellt werden. Damit bspw. eine (geschachtelte)Ausgabe im XML-Format moglich ist, muss das Layout nicht nur die Namen derAttribute kennen, dessen Tupelinformationen verwendet werden, sondern auch dieAnzahl aller Tupel, um schließende XML-Tags korrekt ausgeben zu konnen.

3.8 Unabhangigkeit vom CMS

Damit die Funktionalitat des Datenbankbrowsers (DBBrowser) nicht vom Content-Management-System abhangt, muss der Datenbankbrowser eine Schnittstelle besit-zen, an der alle notwendigen Funktionen zur Verfugung gestellt werden. Die Ap-plikation stellt alle notwendigen Funktionen zur Verfugung, die zum Erstellen vonAusgabemasken notwendig sind (sowohl der Editor, als auch der Interpreter). DieAufgabe des CMS besteht darin, dem Benutzer das Erstellen, Verwalten und Edi-tieren der DBBrowser zu ermoglichen und fur die grafische Darstellung zu sorgen.

Da das CMS bestimmt, wie Content-Elemente erstellt und verwaltet werden,kann diese Aufgabe nicht vom Datenbankbrowser ubernommen werden. Der Daten-bankbrowser muss aber so konfigurierbar sein, dass er an die Bedurfnisse des CMSangepasst werden kann, d.h. dass der Speicherort der DBBrowser eingestellt werdenkann, alle zur Auswahl stehenden DBBrowser angezeigt werden konnen usw.. Bei derIntegration der Applikation muss sich daher keine Gedanken daruber gemacht wer-den, wie die DBBrowser gespeichert werden, wie DBBrowser editiert werden usw.,sondern es muss nur dafur gesorgt werden, das diese Informationen dem Benutzerin ansprechender Art und Weise prasentiert werden.

An einem Beispiel soll dies verdeutlicht werden. Ein DBBrowser wird neu erstellt,und dazu muss im ersten Schritt eine Startrelation gewahlt werden. Das CMS erhaltvom DBBrowser-Editor durch den Aufruf der entsprechenden Methode die Namenaller verfugbaren Relationen. Diese Informationen werden durch das CMS dem Be-nutzer, z.B. in einer Selectbox, dargestellt, aus der er eine Relation wahlen kann.Diese Wahl wird bestatigt und das CMS ubermittelt die Wahl an den DBBrowser-Editor, der nun alle verfugbaren Attribute und Fremdschlusselbeziehungen aus derDatenbank ausliest. Diese Information kann vom CMS angefordert werden und sodem Benutzer die Wahl der auszugebenden Attribute ermoglicht werden. In Abb.

Abbildung 3.6: Datenflussdiagramm zur Abfrage der Attribute einer Relation

3.6 wird dieses Beispiel durch ein Datenflussdiagramm verdeutlicht. Das CMS stellteine Anfrage an den DBBrowser-Editor. Zu einer Relation werden alle Attributeangefordert. Sofern diese Daten noch nicht in der Session verfugbar sind, wird dieAnfrage an die Datenbank gesendet, und anschließend wird das Ergebnis in derSession gespeichert.

Das CMS muss also nur dafur Sorge tragen, dass die Informationen dem Benutzerprasentiert werden und die Auswahl oder gewahlte Aktionen (z.B. Maske editieren)an den Editor des DBBrowsers weiterleiten.

3.9 Zu speichernde Informationen

Durch die Unabhangigkeit des DBBrowsers vom CMS liegt die gesamte Kontrolleder zu speichernden Informationen beim DBBrowser. Da es sich um eine Applikati-on in der Skriptsprache PHP handelt, sind alle Informationen nach der Ausfuhrungder angeforderten HTML- (oder PHP-) Seite verloren, im Gegensatz zu einer Ap-plikation in Java, die die Informationen bis zur Beendigung durch den Benutzerim Speicher halt. Die Verfugbarkeit der Daten bei Webapplikationen ist also starkbegrenzt und nur wahrend der Erstellung einer HTML-Seite verfugbar. Da die In-formationen, wie z.B. die Wahl der Ausgangsrelation, die erstellten Masken usw. biszur Speicherung des DBBrowsers verfugbar sein mussen, wird die Sessionfunktiona-litat von PHP ausgenutzt. Diese wurde mit der Version 4 von PHP eingefuhrt undbasiert auf der Vergabe einer eindeutigen Session-ID.

Mit Hilfe der Sessions lassen sich die Informationen fur die Dauer der Benutzungder Webapplikation speichern. Da das CMS diese Funktionalitat ebenfalls nutzenkann, muss der Editor dies vorher feststellen, damit es zu keinen Konflikten kommt.Sollte das CMS ebenfalls von Sessions Gebrauch machen, durfen Variablen nichtgegenseitig uberschrieben werden. Dies konnte passieren, wenn das CMS und derEditor z.B. eine gemeinsame Sessionvariable mit dem Namen USER haben. Diekorrekte Funktionsweise beider Programme ware nicht mehr gewahrleistet. Um die-ses Problem weitgehend ausschließen zu konnen, werden alle Informationen in demassoziativen Array DBBrowser abgelegt. Es ist sehr unwahrscheinlich, dass das CMSSessionvariablen mit dem Namen DBBrowser benutzt. Die Speicherung der Varia-blen USER muss also folgendermaßen erfolgen:

$_SESSION["DBBrowser"]["USER"] = "admin";

Weiterhin ist zu beachten, dass ein DBBrowser aus mehreren Masken bestehenkann (dies ist dann der Fall, wenn von einer Maske zu einer anderen Maske verwie-sen wird). Diese Informationen mussen wahrend der Erstellung, und spater beimEditieren, ebenfalls wahrend der Benutzung verfugbar sein. Damit sich die Datender Masken nicht gegenseitig uberschreiben, wird das assoziative Array erweitert:

$_SESSION["DBBrowser"][NAME_DER_MASKE]["USER"] = "admin";

Auf diese Art ist sichergestellt, dass sich Masken beim Speichern der Informationnicht gegenseitig uberschreiben. Welche Maske gerade editiert werden soll, muss demEditor mitgeteilt werden (uber eine entsprechende Methode, z.B. useMask).

Alle Informationen werden beim Speichern des DBBrowsers in einer Datei abge-legt. Der Name der Datei entspricht dem Namen des DBBrowsers mit der Endung“php“. Eine Speicherung der Daten in einer Datei hat den Vorteil, dass keine wei-teren Relationen fur den DBBrowser erstellt werden mussen.

Um ein Editieren der erstellten DBBrowser zu ermoglichen, mussen alle notwen-digen Informationen, die wahrend des Erstellens des DBBrowsers vorhanden sind,in der Datei mitgespeichert werden. Mit Hilfe der Serialisierungsfunktion von PHPkonnen die Daten auf eine einfache Art gespeichert und auch wieder geladen werden.Durch die Serialisierung werden in PHP, anders als in Java, nur die Eigenschaftendes Objektes gespeichert, nicht die Methoden.

Die Abbildung 3.7 zeigt den Datenfluss fur den Fall, dass vom Frontend desCMS der Inhalt eines DBBrowsers angefordert wird. Der Interpreter des DBBrowserermittelt den Namen der anzuzeigenden Maske mit Hilfe des Query-String der URL.Dieser liest die Informationen aus der entsprechenden Datei aus. Die abgespeicherteAnfrage wird an die Datenbank gesendet und die Ausgabe erstellt. Der erstellteInhalt wird an das CMS weitergeleitet und dort ausgegeben.

Abbildung 3.7: Inhalt einer Maske wird vom CMS angefordert

3.10 Verwendung mehrerer Datenbanksysteme

Um ein weites Einsatzspektrum zu gewahrleisten, sollte die Anwendung nicht auf einDatenbank-Management-System (DBMS) eingeschrankt sein. Durch die Einfuhrungeines Database-Abstraction-Layer (DBAL) kann diese Beschrankung aufgehoben

werden. Dabei ist zu beachten, dass jedes DBMS spezielle Befehle fur den Zugriffauf das Data-Dictionary hat. Z.B. werden die verfugbaren Tabellen bei einer Oracle-Datenbank anders abgefragt, als bei einer MySQL-Datenbank. Daher sollte es furjedes zu verwendene DBMS eine eigene Klasse geben. In diesen Klassen werden dieDatenbank spezifischen SQL-Anfragen in Methoden gekapselt. Der Zugriff auf dasDBMS erfolgt nur uber diese Klassen, bspw. um die verfugbaren Tabellen abzufra-gen. Alle benotigten Methoden werden in einem Interface zusammengetragen, dassvon den jeweiligen Klassen implementiert wird1.

1PHP4 sieht keine Verwendung von Interfaces vor. Stattdessen wird eine Oberklasse eingefuhrt.

Kapitel 4

Benutzerhandbuch

Das Programmpaket umfasst zwei Applikationen: zum einen existiert die Moglich-keit, neue Datenbankbrowser mit einem Editor zu erstellen und zu editieren. Zumanderen werden durch einen Interpreter die erstellten Datenbankbrowser (DBBrow-ser) geladen und Ausgaben fur die Webseite erstellt. Aus diesem Grund wird mit derEinfuhrung in die Benutzung des DBBrowser-Editors begonnen. Im Anschluß daranwird gezeigt, wie die so erstellten DBBrowser in TYPO3 als Content-Elemente aus-gewahlt werden konnen, die dann vom Interpreter geladen werden und die gewunsch-te Ausgabe erzeugen.

4.1 Voraussetzungen

Die Verwendung des DBBrowsers setzt die Kenntnis mit dem Umgang von TYPO3voraus, d.h. es ist als bekannt angenommen, wie eine neue Webseite erstellt undneue Content-Elemente in TYPO3 angelegt werden konnen.1

Das zugrundeliegende Datenbanksystem ist Oracle 9i/10g. Fur andere Systememuss das Programmpaket entsprechend erweitert werden. Weitere Informationen zurErweiterung des DBBrowsers gibt Kapitel 6.5.

Die verwendete PHP-Version ist 4.3.8. Da TYPO3 in der vorliegenden Version3.6.1 die Verwendung von PHP 5 nicht ermoglicht, kann eine Benutzung mit dieserVersion nicht garantiert werden.

4.2 DBBrowser

In Kapitel 3 wurde das Konzept eines DBBrowsers erlautert. Ein DBBrowser be-steht aus einer oder mehreren Ausgabemasken (kurz: Masken), die einen durch denBenutzer festgelegten Inhalt auf der Webseite ausgeben sollen. Der Inhalt der Maskewird bestimmt durch die gewahlten Relationen und die zwischen ihnen bestehendenVerknupfungen, sowie Ausgabeformatierungen (Layout, gewahlte Attribute usw.).Innerhalb des DBBrowsers sind diese Masken durch Bedingungen (die der Benut-zer festgelegt hat) miteinander verknupft. So ist es moglich, von einer Maske zu

1nachzulesen auf www.typo3.org

Abbildung 4.1: DBBrowser-Prinzip

einer anderen zu gelangen. Abbildung 4.1 verdeutlicht das Prinzip. Masken sinddadurch flexibel einsetzbar, konnen von mehreren Masken aufgerufen werden undselbst ebenfalls auf andere Masken verweisen. Das durch die Verknupfungen entste-hende Netzwerk gewahrleistet das Browsen durch die Datenbank.

Einsteigspunkt in das Netzwerk ist immer die Hauptmaske. Diese wird angezeigt,wenn die entsprechende Webseite aufgerufen wird. Von dort aus kann der Besucherder Webseite (auch: Surfer) zu den anderen Masken gelangen.

4.3 Die Benutzung des Editors

Neue Datenbankbrowser konnen nur im Backend von TYPO3 erstellt und bearbeitetwerden. Zu diesem Zweck wurde der Editor in das CMS integriert und kann dortmit einem Klick auf das Modul DBBrowser gestartet werden (s. Abb. 4.2).

Abbildung 4.2: Menupunkt im CMS

Abbildung 4.3: Menupunkte des Editors

Nach dem Start des Editors stehen drei Menus in einer Selectbox zur Auswahl(s. auch Abb. 4.3):

• EinstellungenVerwaltung der Zugangsdaten fur die Datenbank und wichtiger Verzeichnissefur den DBBrowser.

• neuen DBBrowser erstellenErstellt einen neuen DBBrowser.

• DBBrowser-VerwaltungUbersicht aller erstellten DBBrowser. In der Verwaltung konnen DBBrowsergeladen (zum Editieren) und geloscht werden.

4.3.1 Einstellungen

Einstellungen betreffen sowohl die Zugangsdaten fur die Datenbankverbindung, alsauch die benutzten Verzeichnisse des DBBrowsers.

Unter dem Reiter Datenbank konnen die Zugangsdaten fur die Datenbank-verbindung geandert werden. Benotigt werden die Daten sowohl fur die Benutzungdes Editors, als auch fur die erstellten DBBrowser, um die Daten auf der Webseiteausgeben. Die Zugangsdaten werden nicht zusammen mit dem erstellten DBBrow-ser abgespeichert, d.h. dass durch eine Anderung der Zugangsdaten bereits erstellteDBBrowser moglicherweise nicht mehr funktionieren.

Alle wichtigen Verzeichnisse fur den DBBrowser sind im gleichnamigen Reiterzu finden. Auf diese Weise lassen sich die einzelnen Erweiterungen des DBBrowsergetrennt verwalten.

4.3.2 Einen neuen DBBrowser erstellen

Das Erstellen eines neuen DBBrowsers beginnt immer mit dem Erstellen der Haupt-maske (diese wird angezeigt, wenn die entsprechende Webseite aufgerufen wird). Vondieser Hauptmaske kann auf andere Masken verwiesen werden. Wie weitere Maskenerstellt und wie diese miteinander verknupft werden, wird spater an einem Beispielverdeutlicht.

Wird der Editor aufgerufen, so beginnt der Benutzer mit dem Anlegen der Haupt-maske. In dieser Ubersicht (s. Abb. 4.5) wird dem Benutzer nicht nur das Anlegen

Abbildung 4.4: Reiter Datenbank

der Hauptmaske ermoglicht, sondern auch die Verwaltung aller Masken und dasSpeichern des gesamten DBBrowsers.

Eine Maske besteht aus einer oder mehreren Relationen, die die anzuzeigendenTupelinformationen und Ausgabevorgaben beinhalten. Ausgabevorgaben sind bspw.die Wahl der Attribute, Layout, Einblendung einer Suchfunktion usw.. Bevor jedochdie Ausgabe beeinflusst werden kann, muss festgelegt werden, welche Informationenuberhaupt angezeigt werden sollen, d.h. es mussen diejenigen Relationen ausgewahltwerden, die diese Informationen beinhalten. Die Wahl der Relationen beginnt mitder Startrelation. Alle weiteren Reiter sind aus diesem Grunde deaktiviert. Auf die-se Weise wird ein Ablauf vorgegeben, der das Erstellen eines neuen DBBrowsersleichter gestaltet. Dieses Handbuch orientiert sich an diesem Ablauf. Die jeweiligenUberschriften sind mit den Bezeichnungen der Reiter der Applikation identisch.

Startrelation

In einer Selectbox werden alle verfugbaren Relationen zur Auswahl angeboten (s.Abb. 4.5). Die Wahl der Ausgangsrelation gibt den “Startpunkt“ fur die Maske vor.Zur Auswahl der Startrelation stehen sowohl Tabellen, als auch Sichten, aber nurdiejenigen, auf denen der Datenbankbenutzer Leserechte hat. Wie weitere Relatio-nen eingebunden werden konnen, darauf wird spater noch eingegangen. Eine Start-relation muss gewahlt werden, da Informationen nur aus einer Relation stammenkonnen.

Nach der Wahl der Ausgangsrelation werden durch den DBBrowser-Editor Me-tainformationen zu dieser Tabelle aus der Datenbank gelesen. Dadurch kann derBenutzer spater diejenigen Attribute auswahlen, deren Tupelinformationen auf derWebseite ausgegeben werden sollen. Um das Verknupfen von Relationen und Maskenzu erleichtern, werden Fremdschlusselinformationen zu den Attributen ausgelesenund gespeichert.

Abbildung 4.5: Startrelation wahlen

Attribute

Zunachst erfolgt die Wahl der Attribute. Mit ihrer Wahl kann der Benutzer ent-scheiden, welche Attribute in der aktuellen Maske verwendet werden konnen, d.h.welche Tupelinformationen relevant sind. Tupelinformationen sind dann relevant,wenn sie entweder auf der Webseite ausgegeben werden sollen oder aber fur die Ver-knupfung von Masken notwendig sind. Wie in Kapitel 3 erlautert, werden bei einemVerweis einer Maske (Quellmaske) auf eine andere Maske (Zielmaske) Informatio-nen ubermittelt. Diese Informationen geben der Zielmaske an, welche Informationenangezeigt werden sollen. Wird bspw. von einer Maske, die Filme des Jahres 2004 an-zeigt, auf eine Maske verwiesen, die die im Film mitspielenden Schauspieler ausgibt,dann muss dieser Maske mitgeteilt werden, zu welchem Film sie die Schauspieleranzeigen soll. Dafur wird die ID des Films benotigt. Die Quellmaske benotigt dahersowohl das Attribut Title fur die Auflistung der Filme, als auch das Attribut IDfur die Informationsweitergabe an die Zielmaske.

Die Ubersicht nach dem Klick auf den Reiter Attribute zeigt Abbildung 4.6.In der Groupbox “verfugbare Attribute“ sind alle Attribute aufgelistet, die durchdie erstellten Verknupfungen mit anderen Relationen verfugbar sind. Wurde keineVerknupfung erstellt, dann erscheinen an dieser Stelle nur die Attribute der Start-relation. Zunachst mussen die Attribute gewahlt werden, die fur die Maske wichtigsind. Die Auswahl mehrerer Attribute ist moglich, in dem die STRG-Taste zusam-men mit der Maustaste gedruckt wird. Sollen alle Attribute ausgewahlt werden, sogeschieht dies am schnellsten, indem das erste Attribut angeklickt wird und danachdas letzte (dabei die SHIFT-Taste gedruckt halten). Gewahlte Attribute tauchensowohl in der Groupbox “Ausgabereihenfolge“ als auch “gewahlte Attribute“ auf.

Abbildung 4.6: Der Reiter Attribute

Die Ausgabereihenfolge der gewahlten Attribute kann in der gleichnamigen Group-box geandert werden (s. Abb. 4.6). Mit Hilfe der Pfeile kann das Attribut entwedernach oben oder nach unten bewegt werden. Diese Reihenfolge entspricht dann derAusgabereihenfolge auf der Webseite.

Da nicht alle gewahlten Attribute auch ausgegeben werden sollen, sondern auchfur die Informationsweitergabe an andere Masken benotigt werden konnen, ist esmoglich, die Eigenschaften der Attribute zu verandern. Abbildung 4.7 zeigt am Bei-spiel des Attributs ID der Relation MOVIE die anderbaren Eigenschaften.

• AliasnameDie Attributnamen in der Datenbank sind fur den Besucher der Webseite nichtimmer nutzlich. Deshalb kann es sinnvoll sein, die Attributnamen zu ersetzen,um dem Besucher zu verdeutlichen, welche Art Informationen in der jewei-ligen Spalte gezeigt werden. Die Angabe von MOVIE.TITLE durfte fur denBesucher nicht so aussagekraftig sein, wie Filmtitel. Daher kann dem Attributein Aliasname zugewiesen werden, der auf der Webseite ausgegeben wird. DieLange ist auf 255 Zeichen beschrankt.

• sichtbarNicht immer sollen die Tupelinformationen eines Attributs auch auf der Web-seite ausgegeben werden, sondern dienen nur dazu, Informationen an Zielmas-ken weiterzureichen. Um die Ausgabe auf der Webseite zu unterbinden, kanndas Hakchen der Checkbox entfernt werden. Im Beispiel von Abbildung 4.7dient das Attribut ID nur dazu, die Informationen an die Zielmaske weiterzu-reichen. Daher wird die Ausgabe unterbunden.

• Spaltenhohe, SpaltenbreiteDie Angabe bezieht sich auf die Hohe/Breite der Ausgabetabellen. Alle Infor-mationen auf der Webseite werden in HTML-Tabellen ausgegeben. Wird hier

Abbildung 4.7: Eigenschaften eines Attributs

die Breite oder die Hohe der Spalte angegeben, so ist damit die entsprechen-de HTML-Spalte gemeint. Die Angabe ist in Pixeln, eine Null bedeutet keineAngabe, die Hohe/Breite richtet sich nach den anzuzeigenden Informationen.

• wird interpretiert alsJedes Attribut hat einen zugewiesenen Datentyp in der Datenbank. Dies kannentweder NUMBER, VARCHAR2, DATE oder ein anderer von der Datenbankangebotener Datentyp sein. Der Datentyp gibt Auskunft uber die Tupelinfor-mationen, so speichert ein Attribut vom Typ DATE Datumsinformationen,das Attribut vom Typ VARCHAR2 Strings usw.. Damit Tupelinformationenverandert ausgegeben werden konnen, muss ihnen vom Editor ein Datentypzugewiesen werden. Durch diese Zuweisung wird keine Konvertierung durch-gefuhrt, sondern diese teilt dem Editor nur mit, wie Tupelinformationen auf-zufassen sind. Abbildung 4.7 zeigt, dass das Attribut ID vom Typ NUMBERals Zahl interpretiert wird. Der Editor schlagt entsprechend dem in der Da-tenbank vermerkten Datentyp einen zu interpretierenden Datentyp vor, derdurch den Benutzer jeder Zeit geandert werden kann.

• auszufuhrende FunktionenAbhangig von dem zu interpretierenden Datentyp konnen jedem AttributFunktionen zugewiesen werden. Mit diesen Funktionen konnen Tupelwertevor der Ausgabe manipuliert werden, z.B. konnen Berechnungen durchgefuhrtwerden, eMail-Adressen als klickbare Links dargestellt werden oder aber dasDatum kann formatiert ausgegeben werden.

Mit Hilfe der Funktionen, die den Attributen zugewiesen werden konnen, kanndie Ausgabe in vielerlei Hinsicht verandert werden. In Kapitel 6 kann nachgelesenwerden, wie Funktionen hinzugefugt werden konnen und wie auch die Liste der zu

interpretierenden Datentypen erweitert werden kann. Verfugbar sind der DatentypDatum, String und Zahl, die jeweils unterschiedliche Funktionen zur Verfugung stel-len:

• DatumDatum formatieren: das Datum kann entsprechend der Moglichkeiten vonOracle formatiert ausgegeben werden (angewendet wird die TO CHAR Funk-tion).

• StringAusgabelange begrenzen: begrenzt die auszugebenden Informationen aufdie eingebende Anzahl von Zeichen.klickbare Internetadressen: werden Internetadressen in den Tupelinforma-tionen des Attributes gefunden, werden diese als klickbare Links angezeigt. AlsOptionen konnen das Ziel angegeben werden (z.B. neues Fenster: blank) undder Text fur ein ToolTip. Geht der Besucher der Webseite mit der Maus uberden Link, dann wird der Text des ToolTips angezeigt. Eingegeben werden kannjeder beliebige Text, die Begrenzung liegt bei 255 Zeichen. Mit :VALUE kannsich auf die URL bezogen werden, z.B.: wurde die URL www.uni-hanover.deals URL erkannt, dann wird die Eingabe “klicken Sie hier: :VALUE“ als Er-gebnis “klicken Sie hier: www.uni-hannover.de“ liefern.klickbare eMail-Adressen: gefundene eMail-Adressen werden als klickbareLinks dargestellt.

• ZahlBerechnung durchfuhren: mit den Tupelinformationen konnen beliebigeBerechnungen durchgefuhrt werden. Mit dem Schlusselword :VALUE kannman sich auf den Tupelwert beziehen. Weiterhin kann angegeben werden, wieviele Nachkommastellen das Resultat haben soll.

Fur jede Funktion gibt es spezifische Parameter, z.B. muss zum Formatieren desDatums das Format angegeben werden. Die Eingabe der Parameter erfolgt, nachdemeine dem Attribut hinzu zufugende Funktion gewahlt wurde.

Hinzugefugte Funktionen konnen naturlich editiert und entfernt werden. In denAbbildungen 4.8, 4.9 und 4.10 sind zu jedem Datentyp Beispiele gezeigt.

Verknupfungen

Stehen die auszugebenden Informationen nicht nur in einer Relation, sondern in meh-reren, sollen aber zusammen auf der gleichen Webseite ausgegeben werden, konnendiese mit der Startrelation verknupft werden.

Um eine neue Verknupfung zu erstellen, werden in den Selectboxen (s. Abb.4.11) die zu verknupfenden Relationen ausgewahlt. Die linke Selectbox enthalt dieRelationen, die bereits eingebunden wurden, d.h. es sind die Relationen, die bereitsverknupft wurden. Anfangs ist dort nur die Startrelation enthalten. In der rechtenSelectbox werden alle Relationen aufgelistet, die denselben Besitzer haben wie dieStartrelation. Abbildung 4.11 zeigt an einem Beispiel, wie die Startrelation MO-VIEDB.MOVIE mit der Relation MOVIEDB.PLAYS verknupft werden soll.

Abbildung 4.8: Funktionen des Typs Datum

Abbildung 4.9: Funktionen des Typs String

Abbildung 4.10: Funktionen des Typs Zahl

Abbildung 4.11: Zwei Relationen werden verknupft

Abbildung 4.12: vorgeschlagener Aliasname der Relation

Im folgenden wird durch den Editor fur die gewahlte Relation (im BeispielPLAYS) ein Aliasname vorgeschlagen. Ist eine Relation mit dem selben Namenbereits verknupft worden, d.h. sie ist dem Editor bekannt, wird durch den Editorein Aliasname vorgeschlagen, der nicht mit der bereits bekannten Relation uber-einstimmt. Die Vergabe der Aliasnamen ist bspw. wichtig, wenn die selbe Relationmehrfach eingebunden werden soll. Als Beispiel sei die in Kapitel 3 aufgefuhrte Re-lation Emp gegeben. Fur die Ausgabe der Mitarbeiter und deren Vorgesetzten mussdie Relation mit sich selbst verknupft werden, also zweimal angesprochen werden.Damit eindeutigt ist, ob nun der Mitarbeiter oder der Vorgesetzte gemeint ist, wirdfur die Relation ein Aliasname (z.B. Emp1) vergeben. Der vorgeschlagene Namekann ggf. durch den Benutzer geandert werden (s. Abb. 4.12).

Um die Verknupfung der Relationen abzuschließen, muss im letzten Schritt dieVerbundbedinung eingegeben werden. Erkennt der Editor eine Verbundbedingung(durch vorhandene Fremdschlusselbeziehungen), so ist eine mogliche Verbundbe-dingung bereits eingetragen. Dies kann aber, falls es erforderlich sein sollte, durchden Benutzer jederzeit wieder geandert werden. Abb 4.13 zeigt, dass die zwischenden Relationen MOVIE und PLAYS erkannte Beziehung bereits im Feld “WHERE“eingetragen ist.

Der Klick auf den Button weiter schließt das Erstellen der Verknupfung ab. Zu-vor wird durch den Editor mit Hilfe des SQL-Parser gepruft, ob die eingegebeneVerbundbedingung auch korrekt ist und dem Benutzer bei der Eingabe kein Fehlerunterlaufen ist. Ein Fehler wird mit einer entsprechenden Fehlermeldung angezeigt.Ist kein Fehler aufgetreten, so taucht das Ergebnis in der Groupbox “erstellte Ver-knupfungen“ auf. Wie in Abb. 4.14 zu erkennen ist, ist die erstellte Verknupfungals Link dargestellt (fur beide Relationen werden die Aliase angezeigt). Durch dasAnklicken der Verknupfung ist es moglich diese zu editieren oder gar zu entfernen.Beim Entfernen von Verknupfungen ist daran zu denken, dass dies Auswirkungen aufdie Wahl der Attribute haben kann. Wird die im Beispiel aufgefuhrte Verknupfungmit der Relation PLAYS entfernt, so stehen die Attribute dieser Relation nicht mehrzur Verfugung. Sie konnen daher nicht mehr ausgegeben werden oder fur die Infor-

Abbildung 4.13: Beziehung zwischen den Relationen wurde erkannt

Abbildung 4.14: Die neu erstellte Verknupfung

Abbildung 4.15: Eine neue Maske erstellen

mationsweitergabe an andere Masken dienen.

Masken

Ein Datenbankbrowser besteht aus einer oder mehreren Masken. Die Hauptmaskedient immer als Einstieg, von dort aus kann zu anderen Masken verlinkt werden, umso ein Browsen zu ermoglichen. Weitere Masken konnen im Reiter Masken erstellt,bereits vorhandene editiert, entfernt oder miteinander verknupft werden. Daher un-terteilt sich der Reiter nochmals in die Reiter Untermasken und Maskenverbund (s.Abb 4.15).

Beim Erstellen neuer Masken hat der Benutzer die Moglichkeit, eine neue Mas-ke als Kopie einer existierenden Maske anzulegen. Dabei werden alle Eigenschaftendieser Maske ubernommen. Dies erleichtert dem Benutzer das Anlegen ahnlicherMasken. In Abb. 4.16 wurde eine neue Maske mit der Bezeichnung “Schauspieler“angelegt. Die Bezeichnung der Maske ist nur fur den Benutzer relevant. Alle er-stellten Masken sind in der gleichnamigen Groupbox aufgelistet. Ein Klick auf denMaskennamen ermoglicht dem Benutzer das Editieren der Maske (s. Abb. 4.16).

Ein Klick auf den Link “Maske editieren“ offnet ein Fenster, wie es Abbildung4.17 zeigt. Bei einer neuen Maske wird auch hier mit der Wahl der Startrelationbegonnen. Danach konnen Attribute gewahlt werden und die Startrelation kann mitanderen Relationen verknupft werden.

Damit von einer Maske zu einer anderen Maske verwiesen werden kann, mussendie Masken verknupft werden. Diese Verknupfungen konnen im Reiter Masken-verbund angelegt, bearbeitet und geloscht werden. Das Prinzip der Maskenver-knupfung ist ahnlich dem Verknupfen von Relationen. Auch hier werden zuerst diezu verknupfenden Masken gewahlt. Falls dies sinnvoll ist, kann auch eine Maske mitsich selbst verknupft werden. Naturlich ist eine Mehrfachverkupfung moglich, d.h.eine Maske kann auf mehrere andere Masken verweisen, auf eine Maske kann aberauch von mehreren anderen verwiesen werden.

Nach der Wahl der Masken muss das Linkfeld ausgewahlt werden. Das Linkfeldgibt an, welches Attribut als Verweis zu einer anderen Maske dienen soll. Dieses

Abbildung 4.16: Editieren einer Maske

Abbildung 4.17: Die neue Maske Schauspieler

Abbildung 4.18: Erstellen eines neuen Maskenverbundes

Attribut dient nicht dazu, dessen Tupelinformationen als Parameter zu ubergeben,sondern stellt dessen Tupelwert als gewohlichen HTML-Link dar, damit sich derBenutzer von der Quellmaske zur Zielmaske klicken kann. Abbildung 4.36 zeigt dieNamen der Filme als Link, von denen auf die Maske der mitwirkenden Schauspielerverweisen wird. Es muss nicht unbedingt ein Attribut gewahlt werden. Es gibt auchdie Moglichkeit, selbst einen Text einzugeben, der dann als Link dient. Dazu muss derMenupunkt “benutzerdefinierte Eingabe“ gewahlt werden. In dem Beispiel in Abb.4.18 wurde der Text “es spielen mit...“ eingegeben, um zu den im Film mitspielendenSchauspieler zu verweisen.

Im letzten Schritt muss, wie bei einer Verknupfung von Relationen, die Verbund-bedingung eingegeben werden. Durch den Editor wird gepruft, ob Fremdschlusselbe-ziehungen zwischen den in beiden Masken gewahlten Relationen bestehen. Existierteine solche Beziehung, wie in Abb. 4.18 zu sehen, wird die Verbundbedingung durchden Editor vorgegeben und kann ggf. durch den Benutzer geandert oder erweitertwerden. Bei einem Verbund von Masken ist zu beachten, dass Fremdschlusselbezie-hungen nur bei Attributen der Quellmaske gesucht werden, die auch von Benutzergewahlt wurden. In Abb. 4.18 ist dies zu erkennen. In der Hauptmaske wurdendie Attribute ID, TITLE, YEAR und PLAYER gewahlt. Nur diese Tupel werdenbetrachtet, da auch nur sie Informationen an die Zielmaske weitergeben konnen,wahrend bei der Zielmaske alle Attribute angezeigt werden (die durch Verbundemit anderen Relationen in dieser Maske verfugbar sind). In dem dargestellten Bei-spiel enthalt die Maske Schauspieler nur die Attribute der gewahlten Startrelati-on PERSON. Der Editor hat erkannt, dass zwischen den Attributen PLAYER derQuellmaske und ID der Zielmaske eine Fremdschlusselbeziehung besteht und hat

die Verbundbedingung bereits eingetragen. Bei der Eingabe der Verbundbedingungist darauf zu achten, dass Attribute der Zielmaske das vorangestellte Schlusselwortdestination: enthalten und Attribute der Quellmaske das Schlusselwort source:.Verbundbedingungen beginnen zudem immer mit der Angabe eines Attributs derZielmaske. Um dem Benutzer die Eingabe einer Verbundbedingung zu erleichtern,wird durch einen Klick auf die Attribute in den Selectboxen der jeweiligen Maskeneine korrekte Bezeichnung im Feld fur die Verbundbedingung eingetragen. Im An-schluß an die Eingabe der Verbundbedingung wird diese durch den Editor geparstund auf Korrektheit uberpruft. Erlaubte Vergleichsoperatoren sind: =, <, ≤, >, ≥und <>. Erlaubte logische Operatoren sind OR und AND.

Der neu erstellte Maskenverbund ist in der gleichnamigen Groupbox zu finden(s. Abb. 4.19). Erstellte Verbunde konnen editiert und geloscht werden. Dazu musslediglich der Verbund angeklickt werden.

Abbildung 4.19: der neue Maskenverbund

Ausgabeoptionen

Moglichkeiten zur Beeinflussung der Ausgabe befinden sich unter diesem Reiter. Furdie Ausgabe konnen mehrere Ausgabelayouts zur Verfugung stehen. Im Rahmendieser Arbeit ist nur das Standard-Layout vorhanden2. Die Informationen, die ausder Datenbank ausgelesen werden, werden immer in Form von HTML-Tabellen aufder Webseite ausgegeben.

Das Aussehen der Ausgabetabellen kann mehrfach geandert werden. WichtigsteMittel zum Formatieren von HTML-Tabellen sind Cascading Style Sheets (CSS).CSS ist eine Formatierungssprache, die es Benutzern gestattet, Formatierungen (z.B.Schriften, Abstande) von Dokumenten durchzufuhren. Mit Hilfe von CSS laßt sichauch die Darstellung von Tabellen in vielerlei Hinsicht verandern. Auf die verfugba-ren Moglichkeiten von CSS wird in dieser Arbeit nicht eingegangen3. Style Sheetswerden vom CMS verwaltet, im vorliegenden Fall also von TYPO3. Fur den DB-Browser wird daher keine gesonderte Datei fur die Style Sheets benotigt. Die Zu-weisung von Style Sheets kann fur die Uberschrift der Tabelle und die eigentlichenDaten erfolgen. Die Uberschrift der Tabelle sind die Attributnamen (genauer: dieAliasnamen der Attribute) der Relation(en). Abbildung 4.20 zeigt an einem Beispieldie Verwendung der Style Sheets sowohl fur die Tabelle, als auch fur die Spaltender Attributnamen. Das Ergebnis zeigt Abb. 4.35. Die Ausgabe der Attributnamen

2Anmerkung: es existiert weiterhin ein sehr einfaches XML-Layout. Dies dient aber nur alsBeleg dafur, dass eine Ausgabe im XML-Format moglich ist.

3Die genaue Spezifikation zu CSS kann auf der Website des World Wide Web Consortiums(W3C) nachgelesen werden.

Abbildung 4.20: Layout-Optionen

kann vertikal oder auch horizontal erfolgen. Bei einer vertikalen Ausgabe werden dieAttributnamen fur jedes Tupel wiederholt. Ein Beispiel zeigt Abbildung 4.37. DieEinblendung der Namen kann wahlweise ein- oder ausgeschaltet werden. Um dieAusgabe der Tupel zu beschranken hat der Benutzer die Moglichkeit die Anzahl dermaximal auszugebenden Tupel festzusetzen.

Nach erfolgter Suche kann die Position der Suchfelder geandert werden. Moglichist, die Suchfelder zu Beginn oder am Ende der Ausgabe oder gar nicht anzeigen zulassen. Die Anderung der Position kann sinnvoll sein, wenn die Menge an Suchfel-dern ein Scrollen der Webseite notig macht, um das Ergebnis einsehen zu konnen.Wird die Suche am Ende der Ausgabe angezeigt, so ist die Moglichkeit der Sucheimmer noch gegeben, aber das Ergebnis ist sofort sichtbar. Diese Option hat nureine Auswirkung, wenn eine Suche angezeigt werden soll und Suchfelder vorhandensind.

Weiterhin gibt es die Option, dem Besucher der Webseite eine Sortierungsmoglich-keit anzubieten. Der Besucher kann durch anklicken der Attributnamen festlegen,nach welchem Attribut sortiert werden soll. Abbildung 4.39 zeigt dies an einemBeispiel. Nach dem Klick auf den entsprechenden Attributnamen wird die Sortie-rung ausgelost. Das schwarze Dreieck vor dem Attributnamen gibt dabei an, obaufsteigend oder absteigend sortiert wurde. Die Sortierrichtung kann durch ein er-neuten Klick auf den Attributnamen geandert werden. Diese Option steht nur zurVerfugung, wenn die Attributnamen ausgegeben werden. Ansonsten bleibt die Ak-tivierung ohne Wirkung.

Extras/Suche

Unter dem Reiter Extras/Suche gibt es zwei weitere Reiter: Suche und Exper-tenmodus.

Abbildung 4.21: das Suchfeld Auswahlbox wird erstellt

Um eine Suche innerhalb der Maske zu ermoglichen, mussen dafur Suchfelder an-gelegt werden. Suchfelder konnen z.B. Selectboxen (auch: Auswahlbox) oder Text-felder sein. Mit Hilfe dieser Suchfelder kann der Besucher der Webseite entscheiden,wonach gesucht werden soll. Ein Beispiel einer Suchfunktion zeigt Abbildung 4.38.Mit Auswahlboxen kann der Besucher bestimmte Werte auswahlen, wahrend ihmbei Textfeldern die freie Eingabe ermoglicht wird. Bevor also eine Suche auf derWebseite eingebunden werden kann, mussen dafur die Suchfelder erstellt werden.

In der Groupbox “Suchfelder hinzufugen“ konnen neue Suchfelder angelegt wer-den. Abb. 4.21 zeigt an einem Beispiel das Hinzufugen einer Auswahlbox. Ebensoverfugbar sind die Suchfelder Textfeld und Checkbox. Das Anlegen einer neuen Aus-wahlbox beginnt mit dem Festlegen der Beschreibung. Die Beschreibung wird aufder Webseite vor der Auswahlbox erscheinen, damit der Besucher weiß, welche Be-deutung die Werte haben. Weiterhin kann entschieden werden, ob die Werte statischoder dynamisch sind, d.h. ob die Werte einmal eingegeben werden (statisch) oder ausder Datenbank geladen werden sollen (dynamisch). Fur beide Arten kann zusatzlichangegeben werden, ob die Eintrage in der Auswahlbox sortiert erscheinen sollen.

Abbildung 4.22 zeigt das dynamische Beziehen der Werte. In diesem Fall mussdie Anfrage fur die Werte eingegeben werden. Wichtig hierbei ist, dass das Schlussel-wort SELECT nicht mit eingegeben werden muss4. Zum Abschluß konnen fur diedynamischen Werte (aus der Datenbank) anzuzeigende Werte vergeben werden. Diesist bspw. sinnvoll, wenn die Werte aus der Datenbank fur den Besucher der Webseitekeine Bedeutung haben konnen, sein es Abkurzungen oder Zahlenwerte. Die anzu-zeigenden Werte konnen mit einem Klick auf den Link dargestellte Werte editierenerstellt, geandert oder entfernt werden. Die Eingabe ist nicht erforderlich. Existiert

4aus Sicherheitsgrunden wird das Schlusselwort SELECT immer vor die Eingabe gesetzt, da diegesamte Eingabe ausgefuhrt wird.

Abbildung 4.22: Auswahlbox mit dynamischen Werten

fur einen Wert aus der Datenbank kein anzuzeigender Wert, so wird der Wert ausder Datenbank angezeigt. Abbildung 4.23 zeigt das Fenster, das fur die Eingabeder anzuzeigenden Werte geoffnet wird. Die Eingabe ist auf 255 Zeichen pro Wertbeschrankt.

Wurden die Werte eingegeben, dann muss dies mit einem Klick auf den entspre-chenden Button bestatigt werden. Im Anschluß daran kann ein Defaultwert aus-gewahlt werden. Dieser Defaultwert wird in der Auswahlbox standardmaßig selek-tiert, sobald die Suche angezeigt wird. Wird kein Defaultwert gewahlt, erscheint derEintrag “bitte wahlen“ in der Auswahlbox. Ein Klick auf den Button anlegen erstelltdas Suchfeld. Alle angelegten Suchfelder erscheinen in der Groupbox “Suchfelder“.Ein Klick auf dessen Namen ermoglicht das Editieren und Loschen des jeweiligenSuchfeldes.

Das Anlegen einer Auswahlbox mit statischen Werten erfolgt auf ahnliche Artund Weise. Der einzige Unterschied besteht nur darin, dass keine Anfrage fur dieWerte eingegeben werden muss, sondern die Werte selbst. Abbildung 4.24 zeigt,wie statische Werte fur die Auswahlbox eingegeben werden. Naturlich konnen auchhier fur die Ausgabe andere Werte vergeben werden. Denn die Eingabe des Wertesfur die Auswahlbox muss mit dem Wert aus der Datenbank ubereinstimmen. DasBeispiel zeigt, dass der Wert Adventure der Auswahlbox dem Wert in der Datenbankentsprechen soll, fur den Besucher aber der Begriff Abenteuer eingeblendet wird.Wahlt der Besucher in der Auswahlbox den Begriff Abenteuer aus, wird an dieDatenbank der Wert Adventure ubermittelt.

Dieses Beispiel macht deutlich, dass nun noch nicht festgelegt wurde, an wel-che Attribute die Werte ubermittelt werden, d.h. mit welchen Attributen aus derDatenbank die Werte nun ubereinstimmen mussen. Zu diesem Zweck muss jedesSuchfeld mit Attributen aus der Datenbank verknupft werden. Suchfelder konnenimmer erst mit Attributen aus der Datenbank verknupft werden, nachdem sie erstelltwurden. Diese Vorgehensweise ist daher notig, da ein Suchfeld immer mit mehrerenAttributen verknupft werden kann und fur jedes Attribut auch eine entsprechende

Abbildung 4.23: Ausgabewerte fur dynamische Werte eingeben

Abbildung 4.24: Auswahlbox mit statischen Werten

Abbildung 4.25: Suchfelder konnen mit Attributen verknupft werden

Bedingung eingegeben werden muss. Nach dem Anlegen eines Suchfeldes erscheintdie Option “verknupft mit“ (s. Abb. 4.25). Diese Option erlaubt es, das Suchfeldmit mehreren Attributen zu verknupfen. Ein Klick auf “bearbeiten / hinzufugen“offnet das entsprechende Fenster (Abbildung 4.26).

In der Selectbox stehen alle Attribute zur Verfugung, die der Maske bekannt sind,d.h. die durch Verbundbedingung verfugbar sind. Wird ein Attribut ausgewahlt,muss im letzten Schritt die Bedingung eingegeben werden. Diese legt fest, ob derWert bspw. = oder >= dem Wert in der Datenbank sein soll. Ebenso moglich ist dieVerwendung des Schlusselwortes LIKE. Das Wort COLUMN vor dem Textfeld gibtan, dass dies der Wert aus der Datenbank ist. Um sich auf den ausgewahlten Wertaus der Auswahlbox zu beziehen, muss das Schlusselwort :VALUE benutzt werden.Abbildung 4.26 zeigt an einem Beispiel, wie die eingegebene Bedingung festlegt, dassder Datenbankwert gleich dem Wert aus der Auswahlbox sein soll.

Da ein Suchfeld mit mehreren Attributen verknupft werden kann, kann nochfestgelegt werden, ob der Wert aus der Auswahlbox mit den Werten aller Attributeubereinstimmen muss (AND) oder nur mit dem Wert eines Attributs (OR). Abbil-dung 4.25 zeigt, dass der Wert der Auswahlbox mit den Werten aller verknupftenAttribute ubereinstimmen muss.

Das Anlegen eines Textfeldes oder einer Checkbox als Suchfeld gestaltet sich sehreinfach. Im Falle des Textfeldes kann neben der Bezeichnung noch die maximaleAnzahl von Zeichen eingegeben werden (s. Abb. 4.27). Dies ist sinnvoll, wenn derBesucher der Webseite nicht mehr Zeichen als diese maximale Anzahl eingeben darf.Bleibt dieses Feld leer, so betragt die Anzahl 255 Zeichen. Bei der Checkbox kannder Wert der Checkbox eingegeben werden (s. Abb. 4.28). Dieser Wert wird bei derSuche ubermittelt, wenn sie aktiviert wurde. Mochte man bspw. mit der Checkboxdem Besucher die Moglichkeit geben, nur Filme des Jahres 2004 anzuzeigen, dannsollte der Wert der Checkbox 2004 betragen. Denn bei einem Verbund mit dementsprechenden Attribut kann so die Gleichheit mit diesem Wert (in diesem Falledas Jahr) gepruft werden.

Fur die Suche gibt es nun noch die Moglichkeit, die Anzeige der Suchfunktionzu unterbinden oder aber die Ausgabe zu unterdrucken, wenn nicht gesucht wurde(Abbildung 4.21 zeigt die Groupbox “Eigenschaften der Suche“). Die Ausgabe zuunterbinden kann dann sinnvoll sein, wenn die Maske nur Ergebnisse der Suche anzei-gen soll. Wird in diesem Fall die Seite aufgerufen, erscheint nur die Suchmoglichkeit.

Abbildung 4.26: Suchfeld mit Attributen verknupfen

Abbildung 4.27: Option des Suchfeldes Textfeld

Abbildung 4.28: Option des Suchfeldes Checkbox

Abbildung 4.29: Reiter Expertenmodus

Expertenmodus

Unter dem Reiter Expertenmodus wird dem Benutzer die Moglichkeit gegeben, diedurch die Maske erstellte SQL-Anfrage einzusehen. Diese Anfrage ergibt sich aus dengewahlten Attributen und den verknupften Relationen. Abbildung 4.29 zeigt dies aneinem Beispiel.

Diese Anfrage wird jedesmal ausgefuhrt, wenn die Maske auf der Webseite aufge-rufen wird. Nicht zu sehen sind Bedingungen, die sich durch eine Suche ergeben oderdurch Verweise von anderen Masken. Es soll dem Benutzer lediglich die Moglichkeitgegeben werden, die Ergebnisse durch weitere Bedingungen einzuschranken odereine Sortierungsreihenfolge festzulegen. Die durch den Benutzer eingegebenen Be-dingungen werden bei jedem Aufruf der Maske ausgefuhrt, unabhangig davon, obeine Suche durchgefuhrt werden soll oder von einer anderen Maske verwiesen wurde.

Mit der Sortierungsreihenfolge kann der Benutzer angeben, nach welchen At-tributen die Ausgabe sortiert werden soll. Sie entspricht der ORDER BY-Klauseleiner SQL-Anfrage. Um dem Benutzer die Eingabe dieser Klausel zu erleichtern,

Abbildung 4.30: ORDER BY-Klausel erstellen

kann durch einen Klick auf den Button “erstellen“ ein Fenster geoffnet werden, wiees Abbildung 4.30 zeigt.

In der linken Selectbox werden alle verfugbaren Attribute ausgelistet, auf derrechten Seite diejenigen, die in der ORDER BY-Klausel verwendet werden sollen.Mit Hilfe der entsprechenden Pfeilbuttons konnen nun die Attribute gewahlt wer-den, die in der ORDER BY-Klausel zum Einsatz kommen sollen. Das gewunschteAttribut wird in der linken Selectbox markiert und mit dem entsprechenden Buttonin die rechte Selectbox verschoben. Sind mehrere Attribute fur die Klausel gewahlt,kann die Reihenfolge mit Hilfe der Buttons geandert werden. Ist die Reihenfolgegewahlt, kann diese durch einen Klick auf den Button setzen ubernommen werden.Die erstellte ORDER BY-Klausel erscheint im entsprechenden Textfeld (Abb. 4.30wurde als Ergebnis Movie.TITLE, Movie.YEAR liefern und in dieses Textfeld ein-tragen) und kann ggf. durch den Benutzer geandert werden. Dies kann notwendigsein, wenn bspw. die Titel des Films aufsteigend, und innerhalb der Titel nach Jah-ren absteigend sortiert werden soll.

DBBrowser speichern

Sofern der Datenbankbrowser nicht geladen wurde, gibt es nur die Moglichkeit, ihnunter einem neuen Namen zu speichern. Andernfalls kann der geanderte DBBrowserunter dem selben Namen oder unter einem anderen Namen gespeichert werden. BeimSpeichern des DBBrowsers wird vermerkt, von welchem CMS-Benutzer er erstelltwurde.

4.3.3 DBBrowser editieren

Eine Ubersicht der erstellten DBBrowser erhalt man durch die Wahl des MenusDBBrowser-Verwaltung. Alle erstellten DBBrowser mit Erstellungsdatum unddem Datum der letzten Anderung werden aufgelistet.

Zum Laden eines DBBrowsers braucht nur dessen Name angeklickt zu werden

Abbildung 4.31: Ubersicht aller erstellten DBBrowser

(s. Abb. 4.31). Einen DBBrowser loschen ist durch das Anklicken des rechten Iconsmoglich (s. Abb. 4.31). Einmal geloschte DBBrowser konnen nicht wieder hergestelltwerden!

Eine andere Moglichkeit einen DBBrowser zu laden ergibt sich bei der Arbeit mitTYPO3. Werden alle Content-Elemente einer Webseite aufgelistet, dann werdenneben einer Beschreibung noch zusatzliche Informationen angezeigt. Im Falle desDBBrowsers ist das der Name. Durch Klicken des Links wird auch hier der gewahlteDBBrowser geladen (s. Abb. 4.32).

4.4 Content-Element: DBBrowser

Die durch den Editor erstellten DBBrowser werden wie andere Content-Elementevon TYPO3 behandelt. Sie enthalten die Daten, die auf der Webseite angezeigtwerden sollen und konnen an beliebiger Stelle in der Webseite positioniert werden.Soll ein DBBrowser als Content-Element auf einer Webseite ausgewahlt werden, soist es am einfachsten, den Wizard von TYPO3 zu verwenden. Aus einer Ubersichtvon Content-Elementen kann der DBBrowser ausgewahlt werden.

Durch die Wahl des DBBrowsers als Content-Element wird dem Benutzer vonTYPO3 die gewohnte Ubersicht zum Speichern eines Content-Elementes gezeigt.Zur Auswahl stehen alle bereits erstellten DBBrowser (s. Abb. 4.34). Nach demSpeichern des Content-Elementes kann nun auf der Webseite das endgultige Resultatbegutachtet werden.

Abbildung 4.32: Laden des DBBrowsers in der Ubersicht der Content-Elemente

Abbildung 4.33: Einen DBBrowser als Content-Element erstellen

Abbildung 4.34: einen DBBrowser wahlen

Abbildung 4.35: Beispielausgabe eines DBBrowsers

Abbildung 4.36: Filmnamen dienen als Verweis auf eine andere Maske

Abbildung 4.37: Vertikale Ausgabe der Tupel

Abbildung 4.38: Beispielausgabe der Suchfunktion

Abbildung 4.39: Sortierungsmoglichkeit fur den Besucher

Kapitel 5

Implementierung

Das vorliegende Programmpaket wurde in der Skriptsprache PHP entwickelt. Daszugrunde liegende DBMS ist Oracle 9i/10g.

Das Kapitel gibt einen Einblick in das entwickelte Programmpaket. Es erfolgtzunachst ein Einblick in die Struktur des Data-Dictionarys von Oracle 9i/10g, da die-se im Programm benutzt wird. Anschließend folgt eine Auflistung der entwickeltenKlassen des Programmpakets, sowie eine Beschreibung der beteiligten Komponen-ten.

5.1 Struktur des Data-Dictionarys

Im Data-Dictionary sind Daten uber das Datenbankschema (Metadaten) gespei-chert. Es besteht aus mehreren Sichten, welche sich fur den Benutzer in drei Gruppenaufteilen:

• USERDatensatze in den USER-Views enthalten Informationen, die dem Benutzergehoren, der die Anfrage stellt.

• ALLZusatzlich zu den Daten des Benutzers werden die Tabellen beschrieben, aufdie der Benutzer Zugriff hat.

• DBADiese Views umfassen alle Daten ohne Rucksicht auf den Benutzer.

Im Rahmen dieser Arbeit sind nur vier Sichten der Gruppe ALL von Interesse:

• ALL TABLESDiese Sicht enthalt u.a. Angaben uber die vorhandenen Tabellen. Das AttributTABLE NAME gibt den Namen der Tabelle an, auf die der Benutzer Zugriffhat. Der Editor ermittelt anhand dieser Sicht die fur den Benutzer verwend-baren Tabellen.

• ALL VIEWSAhnlich ALL TABLES. Der Editor ermittelt anhand dieser Sicht die fur denBenutzer verwendbaren Sichten. Mit Hilfe des Attributs VIEW NAME werdendiese Sichten ermittelt.

• ALL CONS COLUMNSZur Ermittlung von Fremdschlusselbeziehungen in Relationen dient diese Sicht.Sie enthalt u.a. die Attribute TABLE NAME, COLUMN NAME und CONS-TRAINT NAME. Durch sie ist es moglich, Informationen fur die Integritats-regeln aller Tabellen zu ermitteln. Eine wichtige Rollte spielt das AttributPOSITION. Besteht ein Fremdschlussel aus mehreren Attributen, so ist dieReihenfolge wichtig, in der sich die Attribute aufeinander beziehen.

• ALL CONSTRAINTSDie Informationen uber die Beziehungen von Relationen und Attributen lie-fert diese Sicht. Constraints definieren die Bedingung, unter denen Datengultig sind. Haufige Constraints sind UNIQUE (U), PRIMARY KEY (P)und FOREIGN KEY (R). Eine solche Bedingung ist in der Spalte CONS-TRAINT TYPE enthalten. Der Name des Constraints ist in der Spalte CONS-TRAINT NAME vermerkt. Die Spalte R CONSTRAINT NAME speichertden Namen des Constraint, der uber einen FOREIGN KEY-Constraint refe-renziert wird. Diese Angabe ist fur den Editor wichtig, um das Attribut zuermitteln, auf das sich der Fremdschlussel bezieht.

5.2 Die PHP-Klassen

5.2.1 DBBrowserEditor

Klasse zum Erstellen und Editieren von Datenbankbrowsern (DBBrowsern). Sie wirddaher im Backend des CMS verwendet. Die Klasse enthalt keine grafische Oberflache,eine Verwendung ohne TYPO3 ist daher nicht moglich. Die Klasse stellt lediglichalle zum Erstellen von DBBrowsern notwendigen Methoden zur Verfugung. Dadurchist die Verwendung des Editors nicht auf TYPO3 beschrankt, sondern kann ebensoin andere CMS integriert werden.

5.2.2 DBBrowser

Interpreter der Parameterdatei. Der Interpreter ist zustandig fur die korrekte Aus-gabe der Masken und wird daher vom Frontend verwendet. Er uberpruft, welcheMaske angezeigt werden soll und ob diese existiert.

5.2.3 Mask

Fur die Ausgabe des Maskeninhaltes verantwortlich. Vom Interpreter werden allebenotigten Komponenten aus der Parameterdatei eingelesen und der Maske zuge-wiesen. Die Maske pruft, ob eine Suche durchzufuhren ist, ob auf die Maske verwiesen

wurde und ob Verweise auf andere Masken existieren. Weiterhin fuhrt die Maske dieSQL-Anfrage aus und schickt das Ergebnis der Anfrage an den DBAttributeContai-ner, der ggf. die Werte andert. Anschließend wird das Ergebnis zur Ausgabe an dasbenutzte Layout geschickt.

5.2.4 DBResult

Tupelinformationen werden in diesem Objekt gespeichert. Dadurch konnen die Tu-pelwerte durch andere Komponenten manipuliert werden, bevor sie schließlich aus-gegeben werden. Gespeichert wird sowohl der Tupelwert, als auch der auszugeben-de Wert. Dadurch steht anderen Komponenten der Wert aus der Datenbank zurVerfugung, auch wenn dieser bereits geandert wurde.

5.2.5 DBAttributeContainer

Alle von der Maske verwendeten Attribute werden von dieser Klasse verwaltet. Sie istdafur zustandig, dass Methoden, die Attributen zugewiesen wurden, ausgefuhrt wer-den und die durch die Methoden manipulierten Werte entsprechend im DBResult-Objekt geandert werden.

5.2.6 DBAttribute

Die Klasse reprasentiert ein Attribut aus der Datenbank. Eindeutig ist das Attributdurch den Namen. Jedes DBAttribute-Objekt ist einem DBDataType-Objekt zuge-ordnet. Der Klasse konnen weitere Eigenschaften zugewiesen werden, wie z.B. einAliasname, der anstelle des Attributnamens der Datenbank ausgegeben wird oder obTupelwerte dieses Attributs ausgegeben werden sollen. Attribute, deren Tupelwer-te nicht ausgegeben werden sollen, dienen dazu, Informationen an andere Maskenweiterzuleiten.

5.2.7 DBDataType

Legt den Datentyp eines Attributs fest. Im vorliegenden Programmpaket enthaltensind die Datentypen Datum, String und Zahl. Jeder Datentyp stellt Methoden zurVerfugung, mit denen die Tupelwerte geandert werden konnen. Bspw. stellt die Klas-se DBDateType eine Methode zur Formatierung des Datums bereit und die KlasseDBNumberType eine Methode, um eine beliebige Berechnung durchzufuhren.

5.2.8 Searchbox

Alle Suchfelder werden von dieser Klasse verwaltet. Suchfelder konnen hinzugefugtoder entfernt werden. Weiterhin sind eine Methode zur Durchfuhrung einer Sucheund eine Methode zur Darstellung der Suchfelder vorhanden.

Da alle Suchfelder dieser Klasse bekannt sind, wird durch diese Klasse auch dieDarstellung der Suchfelder ubernommen. Diese Darstellung wird vom Ausgabelayoutangefordert, das letztendlich entscheidet, ob und wo die Suchfelder angezeigt werden.

5.2.9 SearchItem

Sie dient als Oberklasse fur alle Suchfelder. Vorhandene Suchfelder sind die Aus-wahlbox, das Textfeld und die Checkbox. In der Klasse gespeichert werden außer-dem die Informationen, in welchen Attributen der Datenbank gesucht werden sollund unter welcher Bedingung (bspw. “LIKE ’%:VALUE%’“ oder “=:VALUE“). Dadie Zuordnung zu mehreren Attributen der Datenbank moglich ist, wird außerdemvermerkt, in welcher Beziehung die Attribute stehen, d.h. ob eine Ubereinstimmungder Suchbedingung in einem Attribut (OR) oder in allen (AND) notwendig ist.

Damit eine korrekte Darstellung des Suchfeldes auf der Webseite gewahrleistetist, erstellt jede Klasse seinen eigenen HTML-Tag, der durch die Klasse Searchboxangefordert wird.

5.2.10 LayoutManager

Der LayoutManager ist fur die Verwaltung der verschiedenen Layouts zustandig.Die Klasse stellt eine Factory-Methode, die eine Instanz des gewunschten Layoutszuruckgibt, sofern es vorhanden ist.

5.2.11 MaskLayout

Oberklasse fur alle verfugbaren Layouts. Das Layout bestimmt, wie die Daten aufder Webseite ausgegeben werden. Beeinflusst werden kann das Layout durch Pa-rameter, sofern diese vorgesehen sind. Mit Hilfe verschiedener Layouts ist keineEinschrankung der Ausgabe gegeben.

5.2.12 HTMLFormElement

Diese Klasse dient als Oberklasse der HTML Form-Elemente. Da es moglich sein soll,jedes Ausgabelayout mit Hilfe von Parametern zu beeinflussen, muss die Verwaltungdieser Parameter flexibel sein. Es ware sehr umstandlich fur jede Parameteranderungauch das CMS entsprechend zu andern, damit der neue Parameter dem Benutzer desEditors verfugbar gemacht wird. Durch die Verwendung der HTMLFormElement-Objekte wird weiterhin gewahrleistet, dass die Elemente vom CMS so angezeigtwerden, wie es durch den Designer/Entwickler vorgesehen ist, z.B. als Checkboxoder als Textfeld, ohne die Ausgabe im CMS anpassen zu mussen.

5.2.13 DBRelation

Diese Klasse speichert Informationen uber die verwendete Relation (in der Mas-ke). Sie enthalt DBColumn-Objekte, die die Attribute der Relation reprasentieren.Vermerkt ist weiterhin, ob es sich um eine Tabelle oder eine Sicht handelt. Da In-formationen uber Relationen im Editor haufig gebraucht werden empfiehlt sich dieSpeicherung dieser Informationen.

5.2.14 DBColumn

Die Objekte enthalten Informationen uber die Attribute der verwendeten Relatio-nen. Neben dem Namen sind auch eventuell vorhandene Fremdschlusselbeziehungengespeichert. So kann das Objekt abgefragt werden, ob das Attribut referenziert wirdoder selbst ein Attribut referenziert.

5.2.15 ForeignKeyObject

Informationen uber die Fremdschlussel sind in diesem Objekt gespeichert. Nebendem Namen des Fremdschlussels enthalt diese Klasse Informationen uber die betei-ligten Attribute.

5.2.16 ForeignKeyHandler

Verwaltet alle Fremdschlussel, nicht nur die einer bestimmten Relation.

5.2.17 DBAL

Diese abstrakte Klasse enthalt eine Factory-Methode zum Erzeugen der gewunsch-ten Datenbank-Instanz. Das vorliegende Programmpaket wurde nur mit dem Da-tenbanksystem Oracle 9i/10g getestet, kann eine Verwendung anderer Datenbankendaher nicht garantieren; die Verwendung ist aber durch den Database-Abstraction-Layer vorbereitet.

5.2.18 Database

Alle vom Programmpaket benotigten Methoden fur den Datenbankzugriff sind indieser Klasse gekapselt. Die Methoden regeln ebenfalls den Zugriff auf das Data-Dictionary. Eigentlich als Interface vorgesehen. Da aber PHP in der verwendetenVersion 4.3.8 Interfaces nicht unterstutzt, wurde das Interface zur Oberklasse. DerZugriff auf die Datenbank erfolgt nur uber Instanzen dieser Klasse.

5.3 Programmpaket

Das Programmpaket umfasst zwei Applikationen: zum einen existiert die Moglich-keit, neue Datenbankbrowser mit einem Editor zu erstellen und zu editieren. Zumanderen werden durch einen Interpreter die erstellten Parameterdateien geladen undAusgaben fur die Webseite erstellt. Abbildung 5.1 verdeutlicht das Prinzip.

5.3.1 Der Editor

Der Editor dient zum Erstellen der Datenbankbrowser (DBBrowser). Ein DBBrow-ser umfasst eine oder mehrere Masken, die fur die Ausgabe verantwortlich sind.Ausgangspunkt ist die Hauptmaske. Von ihr aus kann der Besucher der Webseite zuanderen Masken gelangen, sofern dies vorgesehen ist.

Abbildung 5.1: Prinzip der Programmstruktur

Die Klasse DBBrowserEditor ist fur die Verwaltung der Masken zustandig. Sieverwaltet zudem viele weitere Komponenten, wie z.B. die Verknupfung der Masken,Attributeigenschaften und Klassen fur die Eigenschaften von Masken. Das Klassen-diagramm in Abbildung 5.2 zeigt die benotigten Komponenten des Editors.

Zu jedem erstellten DBBrowser wird durch den Editor eine Parameterdatei an-gelegt. In diese wird auch die auszufuhrende SQL-Anfrage (einer jeden Maske) ge-speichert.

DBBrowser werden grundsatzlich uber das CMS TYPO3 erstellt. Der Editorenthalt Methoden, die durch TYPO3 aufgerufen werden, um einen DBBrowser zuerstellen. Alle grafischen Komponenten, die dem Benutzer das Erstellen dieser DB-Browser ermoglichen, werden durch TYPO3 bereitgestellt. Kapitel 5.5 zeigt die In-tegration in TYPO3.

5.3.2 Der Interpreter

Die durch den Editor erstellten Parameterdateien werden durch den Interpreter ein-gelesen. Erstellte DBBrowser werden im CMS mit Webseiten verknupft (s. Kapitel4.4). Der Besucher der Webseite bekommt beim ersten Aufruf der Seite immer dieHauptmaske zu sehen. Sofern der DBBrowser aus mehreren Masken besteht, kannder Besucher von der Hauptmaske zu weiteren Masken gelangen. Uberpruft wirddie URL auf einen bestimmten Parameter, der den (internen) Namen der Maskeubermittelt. Der Parameter maskID enthalt den Namen der anzuzeigenden Maske.Fehlt dieser Parameter wird die Hauptmaske angezeigt. Je nach angeforderter Maskeliest der Interpreter die Parameterdatei ein und erstellt das benotigte Maskenobjekt.Der Maske werden weitere benotigte Komponenten zugewiesen: das zu verwendendeAusgabelayout, Eigenschaften der Suche und Eigenschaften der benotigten Attribu-te. Alle diese Komponenten konnen bei Bedarf erweitert werden (s. Kapitel 6).

Wurde fur die Maske eine Suchmoglichkeit vorgesehen, dann wird die Klasse

Abbildung 5.2: Klassendiagramm des Editors

Searchbox benotigt. Sie enthalt alle Suchfeldobjekte (Klasse SearchItems), die derBenutzer fur die Suche vorgesehen hat.

5.4 Komponenten

5.4.1 Masken

Die Masken sind die Hauptkomponenten des Datenbankbrowsers (Klassendiagramms. Abb. 5.3). Durch die Maske wird festgelegt, was angezeigt werden soll. Wird durchden Besucher eine Webseite aufgerufen, die mit einem DBBrowser verknupft ist,dann wird vom CMS dessen Inhalt angefordert. Der Interpreter stellt fest, welcheMaske angezeigt werden soll und fordert dessen Inhalt an. Abbildung 5.4 zeigt einvereinfachtes Sequenzdiagram, eine Detailierung liefert Abb. 5.5.

Die Maske schickt die SQL-Anfrage, die der Editor in die Parameterdatei ge-schrieben hat, an die Instanz der verwendeten Datenbank. Diese erstellt fur jedesTupel ein DBResult-Objekt und leitet dieses zuruck an die Maske. Der Benutzer hat-te beim Erstellen der Masken die Moglichkeit, im Editor den Attributen Methodenzuzuweisen, wie z.B. eine Berechnung durchfuhren. Die Maske fuhrt daher eine Me-thode der DBAttributeContainer-Instanz aus, die dies uberpruft. Wurden Attributenentsprechende Methoden zugewiesen, werden diese ausgefuhrt und der auszugebendeInhalt der Tupel entsprechend geandert (dies geschieht in den DBResult-Objekten).

Die anzuzeigende Maske kann Verweise auf andere Masken enthalten und/oderauf sie kann verwiesen worden sein. Um dies festzustellen, uberpruft die Maske, fur

Abbildung 5.3: Klassendiagramm der Ausgabemaske

Abbildung 5.4: CMS fordert den Inhalt des DBBrowser einer Webseite an

Abbildung 5.5: DBBrowser fordert den Inhalt einer Maske an

den Fall, dass auf sie verwiesen wurde, den Query-String der URL auf entsprechendeParameter. Erwartet wird der Parameter joinID, der die ID der Verknupfung zwi-schen den Masken enthalt. Diese ID laßt nun den Ruckschluß zu, von welcher Maskeauf die nun anzuzeigende Maske verwiesen wurde. Zwei Masken sind immer durcheine Verbundbedingung verknupft. Die fur die Verknupfung erwarteten Parameterwerden in dem Query-String gesucht, und mit dessen Werten wird die Verbundbe-dingung angepasst. Die Verbundbedingung wurde durch den Benutzer im Editor ein-gegeben und entsprechende Schlusselworter vor die Attribute geschrieben. Mit Hilfeder Schlusselworter wird nun festgestellt, an welcher Stelle im Verbund der Parame-terwert einzusetzen ist. Abbildung 5.6 zeigt ein solches Beispiel. In dem Query-String

Abbildung 5.6: Verbundbedingung wird mit Parameterwerten erganzt

ist der Parameter “param[1]“ hervorgehoben. Die eins in den eckigen Klammern gibtan, dass es sich um den ersten Parameter handelt. Diese Information ist wichtig, fallsmehrere Parameter ubertragen werden. Da auf die anzuzeigende Maske verwiesenwurde, es sich daher um eine Zielmaske handelt, wird das Schlusselwort destination:entfernt und die Angaben der Quellmaske durch den Parameterwert ersetzt. Die aufdiese Weise entstandene Bedingung wird der SQL-Anfrage schließlich hinzugefugt.

Nun kann nicht nur auf diese Maske verwiesen worden sein, sondern die Maskekann selbst ebenfalls Verweise auf andere Masken besitzen. Das Vorgehen ist ahn-

Abbildung 5.7: Klassendiagramm der Layoutkomponente

lich dem eben beschriebenen. Beim Aufruf der Maske wird gepruft, ob diese MaskeVerweise auf andere Masken enthalt. Ist dies der Fall, wird anhand der Verbundbe-dingung festgestellt, welche Parameterwerte benotigt werden. Welche Attributwertedazu gebraucht werden, wird mit Hilfe des Schlusselwortes source: ermittelt. AlleAttribute, vor denen das Schlusselwort auftritt, sind die benotigten Attribute. Mitden Attributwerten wird der Link fur den Verweis erstellt.

Im vorletzten Schritt werden die nun eventuell geanderten DBResult-Objekte andas Layout zur Erzeugung der Ausgabe ubergeben. Die erstellte Ausgabe wird alsString an das Maskenobjekt zuruckgegeben, welches wiederum die Ausgabe an dasCMS weiterleitet, das diese letztendlich ausgibt.

5.4.2 Ausgabelayout

Das Ausgabelayout legt fest, wie die Daten auf der Webseite ausgegeben werden.Damit der Benutzer des Editors die Ausgabe beeinflussen kann, werden durch dasLayout Parameter bereitgestellt, die geandert werden konnen.

Das Klassendiagramm in Abb. 5.7 zeigt, wie Parameter mit dem Layout zu-sammenhangen. Jedem Layout ist eine Menge von HTMLFormElement-Objektenzugeordnet. Diese ermoglichen das Bereitsstellen von Parametern. Die Verwendungder HTMLFormElement-Objekten ist notwendig, da das CMS sonst nicht wissenkann, wie Parameter fur dieses Layout durch den Benutzer gesetzt werden konnen.Beim Standardlayout ist es bspw. moglich, die Attributnamen anzeigen zu lassen.Damit das CMS fur die Wahl des Parameters eine Checkbox erstellt, enthalt je-de Unterklasse von HTMLFormElement eine Methode draw, die die Stringdarstel-lung der Komponente erzeugt. Um dem Benutzer die Parametereinstellung fur dasLayout anbieten zu konnen, bekommt das CMS von dem Layout eine Menge vonHTMLFormElement-Objekten geliefert. Fur jedes einzelne Objekt ruft das CMS diedraw -Methode auf und erzeugt somit die gewunschte HTML-Darstellung.

Auf diese Weise kann ein bestehendes Layout jederzeit, unabhangig von Anderun-

Abbildung 5.8: Ausfuhrung der Methode calculate

gen am CMS, um Parameter erweitert werden. Kapitel 6.3 gibt eine ausfuhrlichereAnleitung zu diesem Thema.

5.4.3 Attribute und Datentypen

Der Benutzer des Editors wahlt Attribute der Relationen aus, deren Tupelwerteentweder auf der Webseite ausgegeben werden sollen oder aber fur die Informations-weitergabe an andere Masken bestimmt sind.

Fur jedes durch den Benutzer gewahlte Attribut wird eine Instanz der KlasseDBAttribute erstellt. Jedes Attribut wird als ein bestimmter Datentyp interpretiert,d.h. dass die Werte aus der Datenbank entweder als Zahl, String oder Datum auf-gefasst werden. Diese Unterscheidung ist wichtig, da fur jedes Attribut, je nachDatentyp, unterschiedliche Methoden angewendet werden konnen. Diese Datenty-pen mussen nicht mit dem in der Datenbank definierten Datentyp ubereinstimmen.Dem Benutzer des Editors wird somit nur die Moglichkeit gegeben, den AttributenMethoden zuzuweisen.

Dem Attribut zugewiesende Methoden werden von der Klasse DBAttribute ver-waltet. Das Sequenzdiagramm in Abbildung 5.8 zeigt an einem Beispiel die Aus-fuhrung der Methode calculate der Klasse DBNumberType. Die Klasse DBAttri-buteContainer verwaltet alle Attribute und ruft deren execute-Methode auf (wennder Inhalt einer Maske angefordert wird). Damit Methoden auf die Tupelwerte ande-rer Attribute zugreifen konnen, wird eine Referenz auf das DBResult-Objekt uber-geben. Die Klasse DBAttribute wiederum ruft mit dieser Referenz die Methodenauf, die hinzugefugt wurden. In dem Beispiel wird die Methode calculate aufgeru-fen, der der Wert aus der Datenbank ubergeben wird. Die Methode gibt den durchdie Berechnung entstandenen neuen Wert zuruck. Dieser neue Wert wird durch dieKlasse DBAttributeContainer fur die Ausgabe gesetzt.

5.4.4 Suchfelder

Das Ermoglichen einer Suchfunktion erfordert das Erstellen mehrerer Suchfelder.Suchfelder sind bspw. Auswahlboxen oder Textfelder. Alle Suchfelder werden in derKlasse Searchbox verwaltet. Jedes Suchfeld ist eine Instanz der Klasse SearchItem.

Informationen werden auf Webseiten durch Formulare gesammelt und ubertra-gen. Fur diese Ubertragung gibt es die POST - und GET -Methode. Der Unterschiedder beiden Methoden besteht darin, dass die GET -Methode den Query-String derURL andert, die POST -Methode nicht. Daher ist die Ubertragung fur viele Infor-mationen mit der GET -Methode nicht zu empfehlen, da der Query-String maximal8192 Zeichen lang sein darf. Aus diesem Grund werden die Werte der Suchfeldermit der POST -Methode ubertragen. Der Maske stehen die Werte durch die globalePHP-Variable $ POST zur Verfugung und konnen durch die entsprechenden Namender Suchfelder abgefragt werden.

Damit eine Suche durchgefuhrt werden kann, pruft die Maske, ob der Parame-ter search ubermittelt wurde. Wurde dieser ubermittelt, wird die executeSearch-Methode der Klasse Searchbox aufgerufen. Damit ein Suchen in mehreren Attributender Datenbank moglich ist, wurden die Namen dieser zusammen mit der vom Benut-zer des Editors eingegebenden Suchbedingung in der Klasse SearchItem gespeichert.Wurde nun die executeSearch-Methode der Klasse Searchbox aufgerufen, wird an-hand der ubermittelten Parameter zuerst festgestellt, fur welche Suchfelder Werteubermittelt wurden. Fur diese Suchfelder werden alle Suchbedingungen mit demubermittelten Wert angepasst und in die SQL-Anfrage integriert. Jedes Suchfeld istdurch eine Bedingung mindestens einem Attribut zugewiesen. Diese Bedingung wirddazu verwendet, die WHERE-Klausel der SQL-Anfrage zu erweitern. Dies schiehtgemaß dem in Kapitel 3.6 entwickelten Konzept. Das Prinzip verdeutlicht das Se-quenzdiagramm in Abbildung 5.9.

5.5 Integration in TYPO3

5.5.1 Voraussetzungen

Die Integration in TYPO3 basiert auf der Version 3.6.1, die im April 2004 freigegebenwurde. Daher kann nicht garantiert werden, dass eine Integration in altere Versionenauf die selbe Art erfolgen kann.

Die Erstellung des notwendigen Moduls und Plugins, die fur die korrekte Arbeits-weise des Datenbankbrowsers verantwortlich sind, erfolgt durch den Kistart Wizard(oder auch Kickstarter), der als Extension fur TYPO3 in der Basisinstallation ent-halten ist und ggf. nur noch aktiviert werden muss.1

5.5.2 Erstellen des Moduls und Plugins

Bevor es uberhaupt moglich ist einen neuen DBBrowser zu erstellen oder DBBrowserals Content-Element zu wahlen (s. Kapitel 2.3.1), muss TYPO3 dafur erweitertwerden. Notwendig sind ein Modul und ein Plugin.

1im Modul Ext Manager

Abbildung 5.9: Prinzip der Ausfuhrung einer Suche

Nach Definition von Kasper Skarhøj beschreibt ein Modul eine Erweiterung desBackend (Administrationsbereich) und ein Plugin stellt eine Erweiterung des Front-end (die Webprasenz) dar. Ein Plugin ist notwendig, damit Daten uberhaupt aufder Webseite dargestellt werden konnen. Das Modul im Backend ist dafur zustandig,dass DBBrowser erstellt und geandert werden konnen.

Mit Hilfe des Kickstart Wizard ist es seit der Version 3.0 von TYPO3 moglich,relativ einfach Module und Plugins zu entwerfen. Die vom Kickstarter erstellten Mo-dule und Plugins enthalten zwar keinerlei Funktionalitat, sondern er dient vielmehrdazu, TYPO3 fur die Verwendung des neu erstellten Moduls/Plugins vorzubereiten.Dafur werden alle notwendigen Dateien erstellt und einige Eintrage an Basisdateienvon TYPO3 vorgenommen.

Neben den Basiseingaben, wie Titel, Beschreibung und Wahl der Kategorie,mussen noch weitere Eingaben vorgenommen werden. Wird als Content-Elementder Datenbankbrowser gewahlt, so soll dem Benutzer eine Auswahl aller vorhan-denen DBBrowser gezeigt werden, aus denen er einen mittels Selectbox auswahlenkann. Dies erfordert die Erweiterung der tt content Relation in TYPO3. Die Relati-on tt content speichert alle notwendigen Informationen zu einem Content-Element,wie z.B. eine Uberschrift, das Publizierdatum, ob es publiziert werden kann usw..Im Falle des Datenbankbrowsers muss gespeichert werden, welcher fur die Ausgabeauf einer Webseite verwendet werden soll. Aus diesem Grund muss die tt contentRelation erweitert werden. Da der Inhalt der Selectbox fur die Ausgabemasken nichtstatisch, sondern dynamisch ist, muss dies an dieser Stelle im Kickstarter vermerktwerden.

Im nachsten Schritt wird mit dem Kickstarter ein neues Plugin erstellt. Dazumussen nur der Name und die Art des Plugin gewahlt werden. Hierbei ist anzugeben,dass der Plugin als Content-Element gewahlt werden kann.

Abbildung 5.10: TYPO3 Kickstart Wizard

Abbildung 5.11: Erweiterung der tt content Relation

Abbildung 5.12: Erstellen des Plugin

Zum Schluß wird das Modul erstellt, mit deren Hilfe die DBBrowser erstelltwerden. Damit das Modul im Administrationsmenu als neues, eigenstandiges Modulerscheint, wird es als neues Modul (nicht als Submodul) erstellt. Ein Submodul hatden Nachteil, dass es als Unterpunkt im Menu auftaucht und dadurch eine bestimmteRolle einnimmt, die es durch das Mainmodul zugeordnet bekommt.

Per Knopfdruck werden die gemachten Eingaben ubernommen und die fur TY-PO3 notwendigen Dateien werden erstellt, die Erweiterung der tt content Relationvorgenommen. Im nachsten Schritt erfolgt die Erweiterung der erstellten Dateiendes Backend und des Frontend, damit ein Erstellen von DBBrowsern moglich istund die Auswahl eines DBBrowsers als Content-Element.

5.5.3 Erweiterung des Moduls

Durch den Kickstarter wurden die erforderlichen Dateien angelegt, mit denen esnun moglich ist, die fur das Erstellen von DBBrowsern notwendige grafische Ober-flache dem Benutzer anzubieten. Das Modul hat lediglich die Aufgabe, dem Benutzerdas Editieren und Erstellen von DBBrowsern zu ermoglichen, die notwendige Funk-tionalitat wird durch die Klasse DBBrowserEditor bereitgestellt. Dadurch ist dieIntegration nicht auf TYPO3 beschrankt, sondern kann in andere CMS auf ahnli-che Art und Weise erfolgen. Alle notwendigen Dateien befinden sich im Verzeichnistypo3conf/ext/user dbbrowser/mod1 von TYPO3. Folgende Dateien wurdenerstellt:

• index.phpWird im Backend das neue Modul aufgerufen, so wird diese Datei angespro-chen. Die grafische Oberflache zum Erstellen der Hauptmaske und Laden von

Abbildung 5.13: Erstellen des Backend-Moduls

DBBrowsern wird von dieser Datei erstellt. Außerdem ist sie fur das Andernder Zugangsdaten fur die Datenbank und die vom Programmpaket verwende-ten Verzeichnisse verantwortlich.

• untermaske.phpDie Datei enthalt die grafische Oberflache zum Erstellen von weiteren Mas-ken. Da die index.php Datei noch weitere, fur TYPO3 wichtige Funktionenenthalt, die zum Erstellen von Untermasken nicht benotigt werden, musstediese Datei zum Erstellen fur weitere Masken angelegt werden.

• library.phpFunktionen, die von den beiden oben genannten Dateien benotigt werden, sindin dieser Datei zusammengefaßt.

• dbbrowser attribute methods.class.phpDas Verknupfen von Attributen und auszufuhrenden Methoden geschieht ineinem weiteren Fenster, das duch diese Datei angezeigt wird.

• dbbrowser change orderby.class.phpEnthalt die grafische Oberflache zum Erstellen der ORDER BY - Klausel.

• dbbrowser search value.class.phpDas Eingeben von statischen Werten fur das Suchfeld Auswahlbox erfolgt ineinem extra Fenster. Fur die grafische Oberflache ist diese Datei verantwort-lich.

• dbbrowser searchitems methods.class.phpSuchfelder konnen mit mehreren Attributen aus der Datenbank verknupft wer-den. Weiterhin kann die Suchbedingung zu jedem Attribut eingegeben werden.Das Layout dazu enthalt diese Datei.

• layout.phpEnthalt samtliche, grafische Methoden, wie z.B. Methoden zum Erstellen vonReitern und Groupboxen.

5.5.4 Erweiterung des Plugins

Damit ein erstellter DBBrowser auch als Content-Element ausgewahlt werden kann,muss der Plugin erweitert werden. Die durch den Kickstart Wizard erstellten Dateienerfullen zum jetzigen Zeitpunkt noch keine Funktionen. Zwei Dateien sind in diesemZusammenhang wichtig:

• class.user dbbrowser tt content user dbbrowser mask.phpDiese Datei ermoglicht, dass spater in einer Auswahlbox alle verfugbaren DB-Browser aufgelistet werden und der Benutzer auswahlen kann, welcher auf derWebseite angezeigt werden soll.

• class.user dbbrowser pi1.phpFur die Ausgabe auf der Webseite ist diese Datei zustandig. Ist ein DBBrowserals Content-Element fur eine Webseite ausgewahlt worden, so wird beim Auf-ruf dieser Webseite die main-Methode der in dieser Datei befindlichen Klasseaufgerufen. Diese erstellt eine Instanz des Interpreters und fordert den auszu-gebenden Inhalt an.

Diese Dateien finden sich im Verzeichnis typo3conf/ext/user dbbrowser/pi1.

5.6 Einschrankungen

Die Applikation wurde in PHP realisiert. In der derzeitigen Version 4.3.8 besitzt PHPnur eine eingeschrankte Moglichkeit der objektorientierten Programmierung. So istdie Deklaration von Interfaces nicht moglich, ebenso nicht die Deklaration vonstatic, public oder privat Variablen, Exception-Handling und die eigenstandigeVerwaltung der eigenen Instanz einer Klasse (Singleton). Weiterhin ist das Uber-laden von Methoden nicht moglich, da PHP eine typenlose Programmierspracheist. Die erneute Verwendung eines bereits benutzten Methodennamens fuhrt immerzu einem Compiler-Fehler. Die Namen der Methoden mussten aus diesem Grundeentsprechend angepaßt werden. Eine Verbesserung der Moglichkeiten zur objekt-orientierten Programmierung ergibt sich erst mit der Version 5 von PHP. Da dieVerwendung von PHP5 mit TYPO3 nicht moglich ist, wurde auf die Entwicklungfur diese Version verzichtet.

Die in dieser Arbeit eingebrachten Sequenz- und Klassendiagramme unterliegeneiner Einschrankung. Sie sehen die Verwendung von Interfaces vor, die aber in PHP4

nicht implementiert werden konnen. An Stelle von Interfaces wurden Klassen ver-wendet, die somit zur Oberklasse der (im Diagramm) Interface implementierendenKlassen werden.

Kapitel 6

Erweiterungsmoglichkeiten

Wichtige Komponenten des Programmpakets wurden modular entwickelt, um dieMoglichkeit der Erweiterung zu bieten. Es soll die Moglichkeit gegeben sein, sowohlden Editor, als auch die durch die Maske erzeugte Ausgabe an kommende Bedurfnis-se anzupassen. Das folgende Kapitel zeigt, wie diese Komponenten erweitert werdenkonnen.

Vorausgesetzt werden Kenntnisse in der Entwicklung mit PHP und HTML.

6.1 Allgemeines

Bei der Entwicklung mit PHP sind, im Vergleich zu Java, einige Einschrankungenzu beachten. Neben den beschrankten Moglichkeiten der objektorientierten Entwick-lung1, ist die Bezeichnung der Dateinamen fur Klassen freigestellt. Auch existiertkeine Package-Struktur (wie in Java). Neue Klassen konnen nur verwendet wer-den, wenn die Dateien der Klassen zuvor manuell eingebunden wurden. Es ist nichtmoglich, Dateien in einem Verzeichnis bspw. mit dieser Anweisung einzubinden:

require_once "*.php";

Damit eine Einbindung der Klassen zentral geschieht, existiert in jedem Ver-zeichnis der Applikation eine package.php Datei, die die Dateien des Verzeichnisseseinbindet. Dateinamen neuer Klassen sind daher in dieser Datei hinzuzufugen.

Die Verwendung der Schlusselworter private, public und protected fur Klassenund Methoden ist erst ab der Version 5 von PHP moglich. Neu erstellte Klassenbieten anderen Klassen bestimmte Methoden an, um die Funktionalitat von Kom-ponenten des Programmpakets zu erweitern. So konnen bspw. Datentypen Methodenbereitstellen, um Tupelwerte zu manipulieren. Welche Methoden das sind, muss inder jeweiligen Klasse durch den Entwickler (z.B. in einem Array) vermerkt sein. Soist garantiert, dass auch nur die Methoden verwendet werden, die der Entwicklerdafur vorgesehen hat. Eine alternative Feststellung, durch die Identifizierung vonpublic-Methoden, gibt es nicht.

1erst ab Version 5 wurden viele dieser Beschrankungen beseitigt

6.2 Datentypen

Der Benutzer des Editors wahlt beim Erstellen einer neuen Maske die Attributeaus, deren Tupelinformationen benotigt werden. Entweder fur die Ausgabe auf derWebseite oder fur die Informationsweitergabe an andere Masken. Damit Tupelin-formationen aus der Datenbank geandert werden konnen, wird jedem Attribut einDatentyp zugewiesen. Dieser Datentyp kann sich von dem in der Datenbank festge-legten Datentyp unterscheiden. Der Benutzer hat die Moglichkeit, dies jederzeit zuandern. Die Zuordnung eines Datentyps zu einem Attribut ermoglicht dem Benutzer,die fur den Datentyp vorhandenen Methoden auf die Tupelwerte anzuwenden. EinBeispiel: in der Datenbank ist das Attribut geburtstag vom Typ Date vorhanden.Da das Attribut in der Datenbank den Typ Date hat, wird dem Attribut durch denEditor automatisch der Datentyp Datum zugewiesen. Wie diese automatische Zu-weisung geschieht wird spater genauer beschrieben. Durch die Zuweisung konnen alleMethoden, die fur den Datentyp Date vorhanden sind, auf die Tupelwerte des At-tributs angewendet werden, so z.B. auch eine formatierte Ausgabe. Diese Zuweisunghat aber nie eine automatische Konvertierung zur Folge, sondern diese Zuweisungdient dazu, bestimmte Methoden auf Tupelwerte anwenden zu konnen. D.h., es istmoglich, das genannte Attribut geburtstag als Zahl zu interpretieren, dies hatte aberkeine Kovertierung in eine Zahl zur Folge. Interessiert man sich bspw. fur das Alter,d.h. es soll mit Hilfe des Geburtsdatums das aktuelle Alter ausgerechnet werden,musste man dazu eine entsprechende Methode im Datentyp Datum hinzufugen.

Abbildung 6.1: Klassendiagramm der Attribut-Komponente

Alle in einer Maske verwendeten Attribute werden von der Klasse DBAttribute-Container verwaltet. Ein entsprechendes Klassendiagramm zeigt Abbildung 6.1. DieMethoden, die fur einen Datentypen verfugbar sind, befinden sich in der entspre-chenden Klasse des Datentyps. Durch das Programmpaket mitgeliefert werden dieKlassen DBDateType (Datentyp: Datum), DBNumberType (Datentyp: Zahl) undDBStringType (Datentyp: String). Jede Methode braucht unterschiedliche Parame-ter. Welche benotigt werden, wird ebenfalls in der jeweiligen Klasse festgelegt. Zu-dem ist es sinnvoll, die durch den Benutzer eingegebenden Werte zu prufen. Wie

dies im Einzelnen genau funktioniert, beschreibt das folgende Kapitel.

6.2.1 Neue Datentypen

Alle Klassen der verfugbaren Datentypen befinden sich im Verzeichnis dbdata-types des Programmpakets. Weitere Datentypen sollten daher ebenfalls in diesemVerzeichnis abgelegt werden. Damit die neue Klasse auch eingebunden werden kann,befindet sich in diesem Verzeichnis die Datei package.php. Sie enthalt die Namender PHP-Dateien, die in diesem Verzeichnis eingebunden werden sollen. Die Datei-namen neuer Klassen mussen daher in dieser Datei hinzugefugt werden.

An einem Beispiel soll das Erstellen eines neues Datentyps demonstriert wer-den. Zunachst wird in dem Verzeichnis dbdatatypes eine neue Datei mit demNamen dbnumbertype.php angelegt und die Datei package.php entsprechendangepasst. Der Eintrag

require_once "dbnumbertype.php";

wird hinzugefugt. Es wird empfohlen, wie bei Java, den Namen der Datei demNamen der Klassen anzupassen. Daher wird die neue Klasse DBNumberTypeheißen und bildet eine Unterklasse von DBDataType. Die Datei dbnumberty-pe.php hat bisher folgenden Inhalt:

class DBNumberType extends DBDataType {

/*** Constructor*/

function DBNumberType() {parent::DBDataType();

Damit dieser Datentyp dem Editor auch zur Verfugung steht, muss die Klasse DBAt-tributeContainer manuell angepasst werden. Diese enthalt neben den durch den Be-nutzer gewahlten Attributen auch ein Array mit allen verfugbaren Datentypen. Inder Methode init wird das Array initialisiert. Es handelt sich um ein assoziatives Ar-ray. Der Index ist der Name der Klasse und der Wert entspricht einer Beschreibung.Im Fall des Beispiels ware der Index daher dbnumbertype und die Beschreibung Zahl.

Der Editor vergleicht den Datentyp des Attributes aus der DB mit dem ihmbekannten Datentypen. Dazu verwendet der Editor die Methode findInterpreted-DataType der Klasse DBAttributeContainer. Der Methode wird als Parameter derDatentyp aus der Datenbank ubergeben. In einer Switch-Anweisung kann nun ent-schieden werden, welcher Datentyp dem Datentyp aus der Datenbank zugewiesenwerden soll. Daher sollte diese Switch-Anweisung angepasst werden, wenn neue Da-tentypen erstellt wurden.

Jetzt ist der neue Datentyp dem Editor bekannt. Allerdings sind fur diesen Da-tentyp noch keine Methoden vorhanden.

Abbildung 6.2: Anforderung verfugbarer Methoden eines Datentyps

6.2.2 Hinzufugen von weiteren Methoden

Die neu erstellte Klasse DBNumberType wird nun um eine Methode erweitert. MitHilfe der Methode soll es moglich sein, die Anzahl der Nachkommastellen von Tu-pelwerten festzulegen.

Damit der Editor spater weiß, welche Methoden der Datentyp zur Verfugungstellt und welche Parameter die Methode benotigt, wird der Konstruktor der Klas-se erweitert. Zwei assoziative Arrays sind fur diese Informationen zustandig. DasArray methodNames speichert den Namen der Methode, sowie dessen Beschrei-bung, und das Array methodParameter speichert zu dem Namen der Methodedie Parameter. Der Konstruktor der Klasse sieht also wie folgt aus:

function DBNumberType() {parent::DBDataType();

//verfugbare Methoden$this->methodNames =array("convert" => "Nachkommastellen festlegen");

//die dazu notwendigen Paramter$this->methodParameter =array("convert" => array("format" => "Anzahl"));

Die neue Methode convert erhalt die Beschreibung “Nachkommastellen festlegen“und hat einen Parameter: die Angabe fur die Anzahl der Nachkommastellen. DasSequenzdiagramm in Abb. 6.2 verdeutlicht, wie Methoden und Parameter durch denEditor abgefragt werden. Das Diagramm zeigt, dass im ersten Schritt die verfugbarenMethoden fur das Attribut abgefragt werden. Die Anfrage wird an das DBDataType-Objekt weitergeleitet, welches das assoziative Array methodNames zuruckgibt.

Werden die Parameter fur eine Methode benotigt, wird auch diese Anfrage an dasDBDataType-Objekt weitergeleitet. Die benotigten Parameter werden von dem as-soziativen Array methodParameter schließlich zuruckgegeben. Aus diesem Grun-de hat das Array als Index den Namen der Methode und als Wert ein weiteres Array,das die Parameter, sowie deren Bezeichnung enthalten.

Jetzt kann die Methode durch den Benutzer bereits ausgewahlt werden und derbenotigte Parameter kann eingegeben werden. Wichtig ist oft eine Prufung der durchden Benutzer eingegebenen Werte. Damit diese gepruft werden, mussen zwei weitereMethoden der Klasse DBNumberType hinzugefugt werden. Die Methode checkMe-thodParameter, die die Methode aus der Oberklasse uberschreibt und die MethodecheckConvertParameter.

Die Methode checkMethodParameter hat zwei Parameter: den Namen der Me-thode und die Parameter. In einer Switch-Anweisung wird der Name der Methodegesucht. Gibt es eine Ubereinstimmung, wird an dieser Stelle die Methode aufge-rufen, die die Parameter fur die entsprechende Methode uberpruft. So konnte dieMethode aussehen:

function checkMethodParameter($name, $parameter){switch($name) {case "convert":return $this->checkConvertParameter($parameter);break;

Fur die Methode convert ist eine eigene Methode zur Uberprufung der Parame-ter vorhanden. Diese Methode wird immer ausgefuhrt, wenn einem Attribut eineMethode hinzugefugt wird.

Die Prufung der Parameter bleibt dem Programmierer uberlassen. Die Methodebekommt im einem assoziativen Array alle Parameter ubergeben, d.h. die Parameter,die die convert-Methode benotigt. Eine Prufung der Anzahl der Nachkommastellenkonnte z.B. so aussehen:

function checkConvertParameter($parameter){if ( !ereg("^[[:digit:]]*$", $parameter["format"]) )return "nur Ziffern für Nachkommastellen eingeben";

Hier ist zu erkennen, dass der Index der Parameter mit dem Namen ubereinstimmt,der zuvor im Konstruktor als benotiger Parameter definiert wurde. Damit der Be-nutzer auch weiß, was er bei der Eingabe verkehrt gemacht hat, sollte eine Fehler-meldung zuruckgegeben werden.

Schließlich fehlt nur noch die Methode convert selbst. Die Methode bekommtsowohl den Wert aus der Datenbank ubergeben, als auch den Parameterwert. Dieconvert-Methode konnte vereinfacht so aussehen:

function convert($value, $parameter){return sprintf("%01.".$parameter["format"]."f", $value);

Da die Variable nicht als Referenz ubergeben wird, muss der neue Wert durch die Me-thode zuruckgegeben werden. Die Klasse DBAttributeContainer sorgt dann dafur,dass der neue Wert im Ergebnis gesetzt wird und somit ausgegeben werden kann.

6.3 Erstellen neuer Ausgabelayouts

Wie die Daten schließlich auf der Webseite ausgegeben werden bestimmt das Layout.Die Ausgabe muss sich hierbei nicht auf die Ausgabe in einfachen HTML-Tabellenbeschranken. Im Rahmen dieser Arbeit wird nur ein Ausgabelayout mitgeliefert, dasStandardlayout2. Es gibt die Daten in einer HTML-Tabelle aus und erlaubt einigeEinstellungen durch den Benutzer. So konnen Style Sheet Informationen gesetztwerden und die Große der Zwischenraume der Tabelle bestimmt werden. Zwar kanndas Layout durch Parameter beeinflusst werden, aber auch hier gibt es Grenzen. Fureine Ausgabe in XML bspw. mußte ein komplett neues Ausgabelayout geschriebenwerden.

Das Verzeichnis layout enthalt die verfugbaren Layouts. Neue Layouts solltendaher in diesem Verzeichnis angelegt werden. Fur das Erstellen eines neuen Layoutssind zwei Klassen wichtig: die Klasse LayoutManager und die Klasse MaskLayout.Die Klasse LayoutManager enthalt zwei wichtige Methoden:

• getAvailableLayoutsdiese Methode gibt alle verfugbaren Ausgabelayouts zuruck. Wurde ein neuesLayout erstellt, muss in dieser Methode das assoziative Array angepasst wer-den. Als Index dient der Name der Klasse und als Wert eine Beschreibung, diedem Benutzer des Editors angezeigt wird.

• getLayoutInstanceFactory-Methode. Sie pruft, ob das Ausgabelayout vorhanden ist und eineInstanz davon erzeugt werden kann.

An einem Beispiel soll nun gezeigt werden, wie ein neues Ausgabelayout ange-legt werden kann. Zuerst wird im Verzeichnis layout eine neue Datei angelegt. Auchhier gilt die Empfehlung, den Namen der Datei an den Namen der Klasse anzu-passen. Erstellt werden soll die Klasse DefaultLayout. Zu Beginn sieht die Klassefolgendermaßen aus:

2Anmerkung: das mitgelieferte XMLLayout dient nur als Beleg dafur, dass eine Ausgabe imXML-Format moglich ist

Abbildung 6.3: Klassendiagramm fur das Layout

class DefaultLayout extends MaskLayout {/*** Constructor*/function DefaultLayout(){parent::MaskLayout();

Diese Methode der Klasse LayoutManager wird entsprechend angepasst:

function getAvailableLayouts(){return array("DefaultLayout" => "Standard");

Jetzt kann das Layout durch den Benutzer des Editors fur eine Ausgabe gewahltwerden, auch wenn noch keine Ausgabe durch das Layout erzeugt wird.

Fur die Ausgabe ist die Methode draw verantwortlich. Diese wird aus der Ober-klasse MaskLayout uberschrieben. Zunachst ist aber noch zu klaren, wie die Tupel-werte ausgegeben werden konnen, bzw. wie das Layout an die Tupelwerte gelangt.Wird der Inhalt einer Maske angefordert, so fuhrt die Maske die entsprechende SQL-Anfrage aus. Jedes Tupel wird in einem DBResult-Objekt gespeichert. Dieses Objektspeichert sowohl den Wert aus der Datenbank, als auch den Wert, der nachher aufder Webseite ausgegeben werden soll. Diese Werte unterscheiden sich, da durch dieAnwendung von Methoden (die den Attributen zugeordnet wurden) die Tupelinfor-mationen geandert worden sein konnen. Da es Komponenten gibt, die auf die Werteaus der Datenbank angewiesen sind, werden beide Werte gespeichert. Es ist daherauch moglich, sowohl den Wert aus der Datenbank, als auch den eventuell geanderten

Wert auszugeben. Die Klasse DBResult hat dafur die Methoden getValueByColumnfur den Wert aus der Datenbank, und die Methode getOutputValueByColumn furden auszugebenden Wert. Beide Methoden erwarten als Parameter den Namen einesAttributes.

Nachdem die Maske alle Daten ausgelesen hat, werden die Objekte an das Layoutubergeben. Weiterhin bekommt das Layout die Instanz des DBAttributeContainerund die Instanz der Searchbox ubergeben. Abbildung 6.3 zeigt das dazugehorigeKlassendiagramm. Anschließend wird die draw -Methode des Layouts aufgerufen.Dem Layout ist somit bekannt, welche Attribute angezeigt werden sollen und ob eineSuche angezeigt werden soll. Das Folgende Beispiel wurde alle Tupelinformationenin einer Tabelle ausgeben:

( 1)function draw(&$mask)( 2){( 3) $content = "<table>";( 4) $dbAttributes = $this->dbAttributeContainer->getOrderedAttributes();( 5)( 6) for($i = 0; $i < count($this->DBRows); $i++)( 7) {( 8) $content .= "<tr>";( 9) foreach($dbAttributes as $attributeName => $attributeObject)(10) {(11) $content .= "<td>" .

$this->DBRows[$i]->getOutputValueByColumn($attributeName) ."</td>";

(12) }(13) $content .= "</tr>";(14) }(15) $content .= "</table>";(16) return $content;(17)}

Damit fur die Ausgabe bekannt ist, fur welche Attribute Tupelinformationenausgegeben werden sollen, konnen diese vom DBAttributeContainer geholt werden.Zeile 4 zeigt die Verwendung der Methode getOrderedAttributes. Diese gibt dieNamen in der Reihenfolge zuruck, in der sie auch auf der Webseite ausgegebenwerden sollen. Die Reihenfolge wurde durch den Benutzer des Editors festgelegt.Als Ruckgabewert der Methode erhalt man ein assoziatives Array, das als Indexden Namen des Attributs und als Wert das DBAttribute-Objekt hat. Wie bereitserwahnt, werden alle Tupelinformationen in DBResult-Objekten gespeichert, diedem Layout durch die Maske ubergeben werden. Alle DBResult-Objekte befindensich im Array DBRows.

Die Methode draw wird mit einem zusatzlichen Parameter aufgerufen, einerReferenz auf das Maskenobjekt. Diese kann benutzt werden, um ggf. weitere In-formationen einzuholen, wie z.B. die Anzahl der betroffenen Datensatze durch dieSQL-Anfrage.

Da die Tupelinformationen eines Attributes nicht unbedingt ausgegeben werdensollen, der Benutzer konnte das im Editor entscheiden, muss dies durch das Lay-out gepruft werden. Die Klasse DBAttribute hat dafur die Methode isVisible. Diegeanderte foreach-Schleife (Zeile 9) wurde daher folgendermaßen aussehen:

foreach($dbAttributes as $attributeName => $attributeObject){if ( $attributeObject->isVisible() )$content .= "<td>" .$this->DBRows[$i]->getOutputValueByColumn($attributeName) ."</td>";

Somit ist sichergestellt, dass nur der Inhalt ausgegeben wird, den der Benutzer desEditors dafur vorgesehen hat.

Damit das Layout beeinflusst werden kann, muss dem Benutzer die Moglich-keit gegeben werden, Parameter zu setzen. Durch HTMLFormElemente bestimmtder Entwickler des Layouts, welche Parameter durch den Benutzer gesetzt werdenkonnen. Auf diese Weise muss nicht jedesmal die grafische Oberflache (im CMS)angepasst werden. Wie das im Einzelnen funktioniert, wird im Folgenden naherbeschrieben.

Das obige Beispiel stellt bis jetzt keine Parameter zur Verfugung und ermoglichtdaher keine Veranderung der Ausgabe. Dem Benutzer soll nun die Moglichkeit ge-geben werden zu entscheiden, ob die Attribunamen ausgegeben werden sollen. Dieslegt die Verwendung von einer Checkbox nahe. Damit im CMS die Wahl des Parame-ters auch durch eine Checkbox erfolgt, wird das entsprechende HTMLFormElement-Objekt benutzt. Die Klasse wird um die Methode getOptionFields erweitert, die dieObjekte der verfugbaren Parameter erstellt und in einem Array zuruckgibt. DieseMethode wird durch das CMS aufgerufen. Sie konnte wie folgt aussehen:

function getOptionFields(){$checkbox = new HTMLCheckbox("showAttributes");$checkbox->setValues("1");$checkbox->setDescription("Attributnamen ausgeben");

return array($checkbox);}

In der Methode wird nun ein neues Checkbox-Objekt erstellt mit dem Namen“showAttributes“, der Wert betragt 1 und die Beschreibung ist “Attributnamen aus-geben“. Die Beschreibung verdeutlicht dem Benutzer, welche Funktion die Checkboxhat. Aktiviert der Benutzer die Checkbox, wird der Wert 1 ubertragen.

Neben der Checkbox gibt es noch weitere HTMLFormElement-Objekte, die er-stellt werden konnen:

• HTMLRadio - Radiobuttons

• HTMLSelect - Selectbox

• HTMLText - Textfeld

• HTMLLabel - Anzeige von Text

• HTMLHidden - Hiddenfeld

Durch die Verwendung der Methode getOptionFields wird nun durch den Edi-tor bei der Wahl des Standardlayouts die Checkbox angezeigt und kann durch denBenutzer aktiviert werden. Damit die Wahl auch eine Auswirkung bei der Ausgabehat, wird die Methode draw entsprechend angepasst:

function draw(&$mask){$content = "<table>";$dbAttributes = $this->dbAttributeContainer->getOrderedAttributes();

//Ausgabe der Attributnamen, sofern durch den Benutzer gewunschtif ( $this->param["showAttributes"] ){$content .= "<tr>";foreach($dbAttributes as $attributeName => $attributeObject)

if ( $attributeObject->isVisible() )$content .= "<td>" . $attributeName . "</td>";

$content .= "</tr>";}

for($i = 0; $i < count($this->DBRows); $i++){$content .= "<tr>";foreach($dbAttributes as $attributeName => $attributeObject){if ( $attributeObject->isVisible() )$content .= "<td>" .$this->DBRows[$i]->getOutputValueByColumn($attributeName) ."</td>";

}$content .= "</tr>";

}$content .= "</table>";return $content;

Alle verwendeten Parameter sind in der Klassenvariable param verfugbar undkonnen dort abgefragt werden. Da als Wert der Checkbox eine eins gesetzt wurde,kann durch obige if-Abfrage festgestellt werden, ob die Attributnamen ausgegebenwerden sollen.

Die HTMLFormElement-Objekte konnen ebenfalls erweitert werden. Sie befin-den sich im Verzeichnis htmlformobjects. Die darin enthaltende Datei package.phpmuss im Falle der Erweiterung der Objekte den Namen der neuen Datei hinzugefugtbekommen, damit das neue Objekt verfugbar ist.

In den Konzepten wurde bereits erwahnt, dass das Layout die Moglichkeit habenmuss, vor der Ausfuhrung der SQL-Anfrage, Methoden der Maske auszufuhren, umbspw. die Anzahl der maximalen Ausgabetupel festzulegen. Diese Moglichkeit hatdas Layout, in dem die Methode executeBeforeDBFetch aus der Superklasse uber-schrieben wird. Der Methode wird als Referenz das Masken-Objekt ubergeben undkann dadurch alle Methoden ausfuhren. Das folgende (einfache) Beispiel legt dieAnzahl der maximal auszugebenden Tupel auf zwanzig fest:

function executeBeforeDBFetch(&$mask){$mask->setMaxRowCount(20);

Mit Hilfe dieser Methode kann auch die SQL-Anfrage ggf. geandert werden, wennbspw. die Sortierung dem Wunschen des Besuchers der Webseite angepasst werdensoll.

Suchfelder anzeigen

Das Layout ist nicht nur dafur zustandig, die Tupelinformationen auszugeben, son-dern auch die eventuell vorhandenen Suchfelder. Dafur ist im Vorfeld zu klaren,ob Suchfelder vorhanden sind und ob die Suche uberhaupt angezeigt werden soll.Die Klasse Searchbox stellt entsprechende Methoden bereit. Die Methode hasEle-ments pruft, ob Suchfelder vorhanden sind und die Methode isVisible gibt an, obdie Suchfunktion angezeigt werden soll. Die Methode draw der Klasse Searchbox er-zeugt schließlich eine HTML-Darstellung der Suchfelder. Die Beispiel-Methode drawder Klasse DefaultLayout muss entsprechend erweitert werden, um die Suchfelderanzuzeigen:

function draw($mask){$content = "";$dbAttributes = $this->dbAttributeContainer->getOrderedAttributes();

if ( $this->searchbox->isVisible() && $this->searchbox->hasSearchItems() ){$content .= $this->searchbox->draw();$content .= "<br />";

... Methode sonst unverandert

Auf diese Weise wird die Darstellung durch die Klasse Searchbox erzeugt. Alter-nativ kann diese Ausgabe auch selbst erstellt werden. Die Methode getAllItemsgibt alle SearchItem-Objekt zuruck. Jedes Objekt besitzt die Methode draw, umdie Stringreprasentation des Suchfeldes zuruckzugeben. Bei dieser Variante mussdas Layout aber dafur sorgen, dass der notwendige FORM-Tag erstellt wird undein “senden“-Button erstellt wird. Bei der Verwendung der draw -Methode aus derKlasse Searchbox ist dies nicht notwendig.

6.4 Suchfelder

Die Erweiterung der verfugbaren Suchfelder ist etwas aufwendiger, als fur die bisherbesprochenden Komponenten. Werden neue Suchfelder erstellt, muss nicht nur dieneue Klasse angelegt werden, wie das bei den bisherigen Komponenten nur notwen-dig war, sondern es muss zusatzlich auch die grafische Oberflache im CMS erweitertwerden. Der Grund liegt in den Vielfalt der Suchfelder. Das Suchfeld Auswahlboxz.B. erlaubt sowohl statische, als auch dynamische Werte. Entscheidet sich der Be-nutzer des Editors dafur, dass die Werte der Auswahlbox dynamisch sind, erscheintzusatzlich ein Feld fur die Eingabe der Anfrage. Diese Anfrage wird gepruft undausgefuhrt. Zum Abschluß werden die betroffenden Werte angezeigt und ein Stan-dardwert kann gewahlt werden. Es handelt sich also um ein schrittweises Vorgehen,das nur im CMS festgelegt werden kann. Dort kann festgelegt werden, dass erst nachder Eingabe der Anfrage (fur die dynamischen Werte) ein Standardwert gewahlt wer-den kann. Aus diesem Grunde muss neben dem Erstellen einer Klasse fur das neueSuchfeld auch die grafische Oberflache im CMS angepasst werden.

Anlegen eines neuen Suchfeldes

Die Klassen der Suchfelder befinden sich im Verzeichnis searchitems. Die Dateipackage.php ist dafur zustandig, alle Klassendateien einzubinden. Wird eine neueDatei erstellt, muss ein entsprechender Eintrag hinzugefugt werden.

Alle Suchfelder sind Unterklassen von SearchItem. Die Klasse fur ein neues Such-feld konnte daher so aussehen:

class SearchCheckbox extends SearchItem{function SearchCheckbox{parent::SearchItem();

Da eine Integration in das CMS durch den Entwickler selbst erfolgen muss, ist nureine weitere Methode notwendig. Diese Methode ist fur die Ausgabe des Suchfel-des zustandig, die Methode draw. Sie gibt an, wie das Suchfeld auf der Webseiteausgegeben werden soll. Z.B.:

function draw(){return "<input type=\"checkbox\"

name=\"".$this->getName()."\"value=\"1\">";

In diesem Beispiel wird der Name des Suchfeldes durch die Klassenmethode getNamebestimmt. Dies hat einen wichtigen Grund: der Entwickler kann die Namen desSuchfeldes nicht selbst bestimmen, da es sonst passieren konnte, dass zwei Suchfelderversehentlich den gleichen Namen bekommen. Der Name eines Suchfeldes wird daherdurch die Klasse Searchbox vergeben und zwar zur Laufzeit. Wird ein neues Suchfeld

erstellt und somit dem Objekt Searchbox hinzugefugt, wird zu diesem Zeitpunkt demSuchfeld ein Name zugewiesen. So ist gewahrleistet, dass Suchfelder nie den gleichenNamen besitzen und außerdem mehrere der gleichen Art verwendet werden konnen(dies ware nicht moglich, wenn der Entwickler den Namen vorgeben wurde). DerWert der Checkbox ist in diesem Beispiel 1. Dieser Wert wird spater mit dem/denverknupften Attribut/en der Datenbanken verglichen. Dieser Wert muss nicht festvorgegeben werden. Er kann auch durch den Benutzer des Editors festgelegt werden.Das Beispiel hat aber noch einen kleinen Schonheitsfehler. Auf der Webseite wurdezwar die Checkbox angezeigt werden, konnte durch den Besucher aktiviert werden,allerdings wurde diese Aktivierung nie angezeigt werden. Wird die Wahl durch denBesucher bestatigt, d.h. klickt er auf den “senden“-Button, ware auf der folgendenSeite die Checkbox nicht mehr aktiviert. Korrigiert sieht die Methode dann so aus:

function draw(){global $_POST;$htmlTag = "<input type=\"checkbox\"

name=\"".$this->getName()."\"";

if ( $_POST[$this->getName()] )$htmlTag .= " checked";

$htmlTag .= " value=\"1\">";

return $htmlTag;}

Alle Suchfelder werden mit der HTTP-POST-Methode ubertragen, daher kann einZugriff auf dessen Werte mit PHP mittels der globalen $ POST-Variable erfolgen.

Das obige Beispiel wird nun um die Moglichkeit erweitert, den Wert der Checkboxdurch den Benutzer festlegen zu lassen. Den Wert der Checkbox merkt sich eineKlassenvariable, die durch entsprechende Methoden geandert werden kann.

class SearchCheckbox extends SearchItem{var $checkboxValue = "";

function setValue($value){$this->checkboxValue = $value;

function getValue(){return $this->checkboxValue;

//die geanderte draw-Methodefunction draw(){global $_POST;

$htmlTag = "<input type=\"checkbox\"name=\"".$this->getName()."\"";

if ( $_POST[$this->getName()] )$htmlTag .= " checked";

$htmlTag .= " value=\"".$this->getValue()."\">";

return $htmlTag;}

Es ist nun die Aufgabe der grafischen Oberflache im CMS dafur zu sorgen, dass derBenutzer die Moglichkeit hat, diesen Wert in einem Textfeld einzugeben. Auch mussder Entwickler dafur sorgen, dass die Methode setValue dieser Klasse aufgerufenwird.

Soweit ware das neue Suchfeld fertig. Die Verknupfung mit Attributen aus derDatenbank und die Anpassung der SQL-Anfrage geschieht durch die Klasse Search-box. Darum muss sich der Entwickler nicht kummern. Das Suchfeld kann allerdingsnoch nicht im Editor ausgewahlt werden. Dazu ist eine Erweiterung der grafischenOberflache im CMS notwendig.

Anpassung der grafischen Oberflache

Eine Anderung der grafischen Oberflache geschieht in der Datei library.php imVerzeichnis typo3conf/ext/user dbbrowser/mod1. Fur die grafische Oberflacheder Suchfelder ist die Methode getSheetExtrasContent zustandig. Auf eine genaueErklarung der Methode wird an dieser Stelle verzichtet, da dies zu weit fuhren wurde.Es bleibt dem Entwickler uberlassen, sich mit der Methode vertraut zu machen. DieMethode ist ausfuhrlich kommentiert und ein Einarbeiten durfte daher nicht schwerfallen.

6.5 Verwendung anderer DBMS

Das vorliegende Programmpaket besitzt nur die Moglichkeit das DatenbanksystemOracle zu verwenden. Die Appikation wurde noch nicht mit einem anderen Daten-banksystem getestet. Daher kann die Verwendung anderer DBMS nicht garantiertwerden. Ggf. mussen weitere Klassen angepasst werden. Neu erstellte Klassen furdie Benutzung anderer DBMS sollten in dem Verzeichnis database abgelegt werden.

Wichtig sind in diesem Zusammenhand nur zwei Klassen: die Klasse DBAL undDatabase. Beide Dateien befinden sich im Verzeichnis classes. Die Klasse DBAL“verwaltet“ die Klassen der verwendbaren Datenbankensysteme. Fur die Erweite-rung ist nur die Methode getInstance wichtig. Sie dient als Factory-Methode undpruft gleichzeitig, ob das gewunschte Datenbanksystem verwendet werden kann. Ineiner Switch-Anweisung wird das zu verwendende Datenbanksystem gesucht und beieiner Ubereinstimmung eine entsprechende Instanz der Klasse zuruckgegeben. Da-her muss die Methode erweitert werden, wenn ein weiteres DBMS benutzt werdenkann.

Die Klasse Database dient als Oberklasse. Da keine Interfaces in PHP deklariertwerden konnen (erst ab Version 5), mussen alle Klassen fur weitere DBMS von dieserKlasse abgeleitet werden. Die Klasse Database enthalt alle Methoden, die vom Pro-grammpaket benotigt werden und sollten daher in den Unterklassen entsprechenddem DBMS angepasst werden. Auf eine Auflistung der Methoden wird an dieserStelle verzichtet und auf die PHPDoc. verwiesen.

Anhang A

Installation

Die Installation der Applikation, als neue Erweiterung (Extension) fur TYPO3, setzteine einsatzfahige Version von TYPO3 voraus. Erweiterungen konnen im Backendvon TYPO3 verwaltet werden. Es wird empfohlen, den Benutzer admin dafur zuverwenden.

Anpassung an die Verzeichnisstruktur

Vor der Installation der neuen Erweiterung muss dieser das Verzeichnis mitgeteiltwerden, in dem sich alle Extensions von TYPO3 befinden. TYPO3 speichert al-le Erweiterungen in einem bestimmten Verzeichnis. Die Angabe des Speicherortesist notwendig, damit die Applikation alle benotigten PHP-Dateien einbinden kann,sowohl im Backend als auch im Frontend. Leider kann dies nicht automatisch pas-sieren, da TYPO3 im Frontend keine Moglichkeit vorsieht, den Speicherort der Er-weiterungen abzufragen. Fur die Applikation ist aber auch im Frontend die Angabedes Speicherortes wichtig, um benotigte Dateien an dieser Stelle einzubinden. Da-mit diese Angabe auch im Frontend verfugbar ist, muss die Datei localconf.phpim Verzeichnis typo3conf angepasst werden. Nach den Kommentaren in den erstenZeilen der Datei ist folgendes einzutragen:

define("DBBROWSER_DIR", ABSOLUTER_PFAD_ZUR_APPLIKATION);

Als Beispiel sei angenommen, dass sich die Erweiterungen von TYPO3 in dem Ver-zeichnis typo3/typo3conf/ext/ befinden. Dann lautet die Angabe des Pfades:

define("DBBROWSER_DIR", "/typo3/typo3conf/ext/user_dbbrowser/dbbrowserApp");

Das Verzeichnis user dbbrowser/dbbrowserApp ist das Verzeichnis, das fur die neueErweiterung automatisch angelegt wird und ist daher bei jeder Installation identisch.Lediglich das Standardverzeichnis der Erweiterungen kann variieren.

Extension installieren

Erweiterungen in TYPO3 werden in Form von Dateien im t3x - Format ausgeliefert1

1es wird angenommen, dass dem Leser diese Datei vorliegt

Abbildung A.1: TYPO3 Extension Manager

und uber den Extension Manager installiert. Dieser ist im Menupunkt Toolsangeordnet (s. Abb. A.1).

Der Extension Manager verwaltet alle Erweiterungen in TYPO3. Es konnenErweiterungen hinzugefugt, aktiviert, deaktiviert oder auch geloscht werden. Deak-tivierte Erweiterungen werden nicht gleich geloscht, sondern stehen in TYPO3 nichtmehr zur Verfugung, konnen aber jederzeit wieder aktiviert werden.

Der Extension Manager bietet verschiedene Menus an (s. auch Abb. A.2):

• Loaded ExtensionsUbersicht uber alle aktivierten Erweiterungen. Diese konnen an dieser Stelleauch deaktiviert werden.

• Available Extensions to installDieser Menupunkt zeigt alle verfugbaren Erweiterungen an, sowohl aktivierteals auch deaktivierte.

• Import Extensions from online repositoryErmoglicht die Installation neuer Erweiterungen, aber nicht nur vom Online-Repository. Das Online-Repository ist eine große Sammlung aller verfugbarenExtensions2. Jeder Entwickler kann seine Erweiterung zum Download anbieten.

• Make new ExtensionDieser Menupunkt erscheint nur, wenn der Kickstart-Wizard als Erweiterunginstalliert ist. Mit seiner Hilfe konnen Erweiterungen fur TYPO3 erstellt wer-den.

• SettingsZugangsdaten fur das Online-Repository konnen hier eingetragen werden.

Fur die Installation der Applikation ist der Menupunkt Import Extensionfrom online repository zu wahlen. Die Bezeichnung des Menupunktes ist viel-leicht etwas unglucklich gewahlt, denn an dieser Stelle konnen auch Erweiterungenhinzugefugt werden, die sich nicht im Online-Repository befinden.

Abbildung A.3 zeigt die Ubersicht nach der Wahl des Menupunktes. Fur dieInstallation des Programmpakets dieser Arbeit ist nur die entsprechende t3x Da-tei zu ubertragen. Dafur muss der Ort der Datei mit Hilfe des “Browse“-Buttons

2verwaltet vom TYPO3-Team auf typo3.org

Abbildung A.2: Menupunkte des Extension Managers

Abbildung A.3: Extension ubertragen

Abbildung A.4: Extension aktivieren

angegeben werden. Die Checkbox “Overwrite any existing extension!“ ist nur zuaktivieren, wenn bereits eine Version der Erweiterung installiert ist und diese ak-tualisiert werden soll. Durch einen Klick auf den Button Upload extension filewird die Datei ubertragen. Anschließend muss die Erweiterung durch einen Klick aufInstall extension aktviert werden (s. Abb. A.4). Zum Abschluss muss die Relationtt content von TYPO3 erweitert werden. Dies ist notwendig, damit die gewahl-ten DBBrowser mit einer Webseite verknupft werden konnen. Dies wird mit einemKlick auf den Button Make updates bestatigt (s. Abb. A.5). Die Installation derErweiterung ist nun abgeschlossen.

Abbildung A.5: Installation abschließen

Damit die neue Erweiterung im Menu des CMS erscheint, muss sich der Benutzererneut ins CMS einloggen.

Zugangsdaten fur die Datenbank

Bevor neue Datenbankbrowser erstellt werden konnen, mussen die Zugangsdaten furdie Datenbank eingegeben werden. Dies ist mit Hilfe der Applikation moglich (s. Ka-pitel 4.3.1). Alternativ kann die Konfigurationsdatei db-ini.php manuell angepasstwerden. Sie befindet sich im Verzeichnis conf der Applikation.

Abbildungsverzeichnis

2.1 Aufbau eines Content-Management-Systems . . . . . . . . . . . . . . 42.2 Templatekonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Architektur von TYPO3 (Quelle: www.typo3.org) . . . . . . . . . . . 8

3.1 DBBrowser-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 ER-Modell des DBBrowsers . . . . . . . . . . . . . . . . . . . . . . . 133.3 ER-Modell der verwendeten Attribute . . . . . . . . . . . . . . . . . . 153.4 Ablauf bei der Anforderung eines Maskeninhaltes . . . . . . . . . . . 193.5 Architektur der Applikation . . . . . . . . . . . . . . . . . . . . . . . 203.6 Datenflussdiagramm zur Abfrage der Attribute einer Relation . . . . 213.7 Inhalt einer Maske wird vom CMS angefordert . . . . . . . . . . . . . 22

4.1 DBBrowser-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2 Menupunkt im CMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3 Menupunkte des Editors . . . . . . . . . . . . . . . . . . . . . . . . . 274.4 Reiter Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5 Startrelation wahlen . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.6 Der Reiter Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.7 Eigenschaften eines Attributs . . . . . . . . . . . . . . . . . . . . . . 314.8 Funktionen des Typs Datum . . . . . . . . . . . . . . . . . . . . . . . 334.9 Funktionen des Typs String . . . . . . . . . . . . . . . . . . . . . . . 334.10 Funktionen des Typs Zahl . . . . . . . . . . . . . . . . . . . . . . . . 344.11 Zwei Relationen werden verknupft . . . . . . . . . . . . . . . . . . . . 344.12 vorgeschlagener Aliasname der Relation . . . . . . . . . . . . . . . . . 354.13 Beziehung zwischen den Relationen wurde erkannt . . . . . . . . . . . 364.14 Die neu erstellte Verknupfung . . . . . . . . . . . . . . . . . . . . . . 364.15 Eine neue Maske erstellen . . . . . . . . . . . . . . . . . . . . . . . . 374.16 Editieren einer Maske . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.17 Die neue Maske Schauspieler . . . . . . . . . . . . . . . . . . . . . . . 384.18 Erstellen eines neuen Maskenverbundes . . . . . . . . . . . . . . . . . 394.19 der neue Maskenverbund . . . . . . . . . . . . . . . . . . . . . . . . . 404.20 Layout-Optionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.21 das Suchfeld Auswahlbox wird erstellt . . . . . . . . . . . . . . . . . . 424.22 Auswahlbox mit dynamischen Werten . . . . . . . . . . . . . . . . . . 434.23 Ausgabewerte fur dynamische Werte eingeben . . . . . . . . . . . . . 444.24 Auswahlbox mit statischen Werten . . . . . . . . . . . . . . . . . . . 444.25 Suchfelder konnen mit Attributen verknupft werden . . . . . . . . . . 45

4.26 Suchfeld mit Attributen verknupfen . . . . . . . . . . . . . . . . . . . 464.27 Option des Suchfeldes Textfeld . . . . . . . . . . . . . . . . . . . . . . 464.28 Option des Suchfeldes Checkbox . . . . . . . . . . . . . . . . . . . . . 474.29 Reiter Expertenmodus . . . . . . . . . . . . . . . . . . . . . . . . . 474.30 ORDER BY-Klausel erstellen . . . . . . . . . . . . . . . . . . . . . . 484.31 Ubersicht aller erstellten DBBrowser . . . . . . . . . . . . . . . . . . 494.32 Laden des DBBrowsers in der Ubersicht der Content-Elemente . . . . 504.33 Einen DBBrowser als Content-Element erstellen . . . . . . . . . . . . 504.34 einen DBBrowser wahlen . . . . . . . . . . . . . . . . . . . . . . . . . 514.35 Beispielausgabe eines DBBrowsers . . . . . . . . . . . . . . . . . . . . 524.36 Filmnamen dienen als Verweis auf eine andere Maske . . . . . . . . . 524.37 Vertikale Ausgabe der Tupel . . . . . . . . . . . . . . . . . . . . . . . 534.38 Beispielausgabe der Suchfunktion . . . . . . . . . . . . . . . . . . . . 534.39 Sortierungsmoglichkeit fur den Besucher . . . . . . . . . . . . . . . . 54

5.1 Prinzip der Programmstruktur . . . . . . . . . . . . . . . . . . . . . . 605.2 Klassendiagramm des Editors . . . . . . . . . . . . . . . . . . . . . . 615.3 Klassendiagramm der Ausgabemaske . . . . . . . . . . . . . . . . . . 625.4 CMS fordert den Inhalt des DBBrowser einer Webseite an . . . . . . 625.5 DBBrowser fordert den Inhalt einer Maske an . . . . . . . . . . . . . 635.6 Verbundbedingung wird mit Parameterwerten erganzt . . . . . . . . . 635.7 Klassendiagramm der Layoutkomponente . . . . . . . . . . . . . . . . 645.8 Ausfuhrung der Methode calculate . . . . . . . . . . . . . . . . . . . 655.9 Prinzip der Ausfuhrung einer Suche . . . . . . . . . . . . . . . . . . . 675.10 TYPO3 Kickstart Wizard . . . . . . . . . . . . . . . . . . . . . . . . 685.11 Erweiterung der tt content Relation . . . . . . . . . . . . . . . . . . . 685.12 Erstellen des Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.13 Erstellen des Backend-Moduls . . . . . . . . . . . . . . . . . . . . . . 70

6.1 Klassendiagramm der Attribut-Komponente . . . . . . . . . . . . . . 746.2 Anforderung verfugbarer Methoden eines Datentyps . . . . . . . . . . 766.3 Klassendiagramm fur das Layout . . . . . . . . . . . . . . . . . . . . 79

A.1 TYPO3 Extension Manager . . . . . . . . . . . . . . . . . . . . . . . 90A.2 Menupunkte des Extension Managers . . . . . . . . . . . . . . . . . . 91A.3 Extension ubertragen . . . . . . . . . . . . . . . . . . . . . . . . . . . 91A.4 Extension aktivieren . . . . . . . . . . . . . . . . . . . . . . . . . . . 92A.5 Installation abschließen . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Erweiterung eines Content Managemant Systems um die ... · Ziel dieser Arbeit ist die Erweiterung...

Documents

Möglichkeiten der Erweiterung - EntwicklerCamp€¦ · Möglichkeiten der Erweiterung • IBM Connections Funktionalitäten • IBM Connections Produkt AddOns • Widgets • Zusätzliche

Number Systems - ecwildcatmath.weebly.com€¦ · Number Systems - ecwildcatmath.weebly.com ... Number Systems

Katalog 2012 Erweiterung-www - Copy

Statistische Auswertungsverfahren mit SPSS SASPSS_Skript_final.pdf · Statistische Auswertungsverfahren mit SPSS 4 Fachhochschule Ingolstadt Prof. Dr. Andrea Raab Das Programmpaket

Hadoop Eine Erweiterung für die Oracle DB? - doag.org · Oracle Certified Professional Exadata Certified Oracle Engineered Systems •Exadata •Exalytics ... matthias.fuchs@capgemini.com

Programmpaket zur Analyse des Thermischen Verhaltens von Baukonstruktionen mit Wärmebrücken

Erweiterung VERA Projektbeschreibung

MaterialderFolienzurVorlesung ... · Die Graﬁken wurden mit dem Statistik-Programmpaket R erzeugt. Der genutzte Pro-grammcodeund diezugrundeliegenden DatenkönnenvonderWebseitezur

Hämodynamik-Modul-Erweiterung - treumedizin.de · Hämodynamik-Modul-Erweiterung Philips M3012A Technische Information Leistungsmerkmale Die Hämodynamik-Modul-Erweiterung wird nur

Produktkatalog - SOLAR-COMPUTER · PDF file3 Software zur Bewertung der Energieefﬁ zienz Verbrauchsabhängiger Energieausweis Programmpaket zum schnellen und einfachen Berechnen

Programmpaket UHYDRO - Sachsen1 Sächsisches Landesamt für Umwelt, Landwirtschaft und Geologie Umweltinformationssystem (UIS) Anleitung zum Erfassungsprogramm für geologische und

WEICHTEILANALYSE UND MODELLVERMESSUNG IN DER ... · 2.4 PictranMed PictranMed ist eine Erweiterung des Pictran-Systems für digitale Photogrammetrie (Technet Berlin/Stuttgart). Dabei

Kartenliste zur Pokémon-Sammelkartenspiel-Erweiterung

Grundlegendes Zur Erweiterung Der Heilkunst

Lignum arts Kollektion: Ästhetisch wie tech- · 200 LA_T03_E10 2010 3.494 € 4.368 € 4.543 € 5.242 € Erweiterung 50cm Erweiterung 70cm Erweiterung 100cm - Seite 45 - technische

RAID oder WAS? · Axel – C. Rosenberg Pillar Data Systems Deutschland GmbH Axel – C. Rosenberg Pillar Data Systems Deutschland GmbH ... * SAN-Erweiterung nach 12 Monaten für

Geschäftsbericht 2013 - nowhow · 2015-06-09 · ist (Leasing Portal) basierend auf Apache OFBiz • Erweiterung des internen Systems ISGate mit einem Modul „Leasing“ für die

Erweiterung IZ Vorau

1) Download Programmpaket: Vector NTI Advance 9.1

DATENAUSWERTUNG MIT SPSS - ph-freiburg.de · zwischenzeitlich PASW (Predictive Analysis SoftWare). Das angebotene Programmpaket wurde im Das angebotene Programmpaket wurde im Laufe