================================================================================ Datenbankanwendung Universitätsmuseen und -sammlungen in Deutschland ================================================================================ 2009-10-04, martin.stricker@gmail.com Die Datenbankanwendung Universitätsmuseen und -sammlungen in Deutschland ist eine auf dem Zend Framework basierende Objekt-orientierte PHP5-Anwendung. Datenbank-Backend ist MySQL 5.0, als Javascript Framework für Frontend Scripting dient jQuery. 1. Dokumentation Überblick 2. Anwendung Überblick 3. Kontakt 1. Dokumentation Überblick ================================================================================ EINFUEHRUNG Dieses Dokument INSTALLATION Installation der Anwendung MySQL Datenbank und MediaWiki (optional) PACKANDGO Vorbereitung zur Migration ROUTINEN Erläuterung einfacher Routinen, die im laufenden Betrieb notwendig werden könnten und die nicht eine tiefgehende Kenntnis der Anwendungstruktur erfordern Code-Dokumentation Packages (Erläuterung siehe unten): - "Universitaetssammlungen" (Action Controllers der Zend Framework Anwendung) - "ST2-Library" (Klassen, die die Anwendungslogik enthalten) - "ZX_ViewHelper" (Hinzugefügte Zend View Helpers) 2. Anwendung Überblick ================================================================================ Die generelle Architektur der Anwendung folgt dem Model-View-Controller Muster (MVC), das eine anwendungssteuerne Schicht (den Controller) logisch von den Komponenten eigentliche Anwendungslogik (die unabhängig von einer konkreten Implementierung ist, Model) und View - den Teilen, die die (graphische) Ausgabe übernehmen - trennt. Dabei werden die MVC Komponenten des Zend Framework, insbesondere Zend_Application, Zend_Controller und Zend_View verwendet. Controller ========== Der Controller besteht aus zwei Ebenen: - dem Front Controller, der die Anwendung von Grund auf konfiguriert, die Requests auswertet und an einen spezifischen - Action Controller routet. Dieser Action Controller führt request-spezifische Aktivitäten durch und bedient sich dabei der Klassen und Methoden der ST2-Library (siehe unten). Außerdem konfiguriert er ein für die Anfrage spezfisches View Object. Nach Abschluss der Aktivitäten des Action Controller steuert der Front Controller die Ausgabe der Anwendung: Layout (der Rahmen, der praktisch auf jeder Seite gleich oder ähnlich ist, mit Seitenhead und linker Seiten- leiste) und das request-spezifische View Object. Der Front Controller wird mittels Zend_Application konfiguriert und gesteuert. Diese Dateien sind von zentraler Bedeutung: /application/Bootstrap.php Die zentrale Bootstrap Datei /application/configs/application.ini Die zentrale Konfigurationsdatei im INI Format Von besonderer Bedeutung sind die in application.ini konfigurierten Routes, die die URL-Parameter auf Action Controllers und deren Actions abbilden und routen. Dabei herrscht prinzipiell ein einfaches Prinzip: - der erste URL-Parameter ergibt den Action Controller - der zweite URL-Parameter ergibt die Action Die Action Controller der Anwendung finden sich in der Code Dokumentation im Package "Universitaetssammlungen" und im Verzeichnis: /application/controllers/ Beispiel: URL: {basispfad}/index/orte (Universitätsorte und Universitäten) Controller: IndexController Action: orteAction() Alle Action Controllers haben einen anwendungsweiten Basiscontroller zum Parent: (Package ST2-Library) class ST2_Controller_USM2Application /ST2/Controller/USM2Application.php Außerdem ist für Action Controllers, die eine vollständige HTML Ansicht steuern (also kein AJAX und keine URL-Redirects am Ende der Action) noch ein spezieller Controller dazwischen geschaltet: (Package ST2-Library) class ST2_Controller_StandardLayout /ST2/Controller/StandardLayout.php Diese beiden Controller Klassen enthalten Methoden und Routinen, die allen Action Controllern zur Verfügung stehen. Zudem registrieren sie Datenbankadapter (Zend_Db) und Session Namespaces (Zend_Session) für die Controller und die View Objects. Model: ST2-Library ================== Bei der Erfüllung ihrer Aufgaben nutzen die Controller Actions die Klassen und Methoden der ST2-Library. Diese enthält die zentrale Anwendungslogik der Datenbankanwendung: Initialisierung, Retrieval und Bearbeitung von Daten- objekten, Entities genannt, und Vokabularen. Klassen zur Ausgabe von Daten in Datenblättern, Formulare, Text Bearbeitung, Datenbank Transaktionen, Workflows und weitere spezielle Funktionen. Die ST2-Library ist im Package "ST2-Library" ausführlich dokumentiert. Ihre Files sind im Verzeichnis /application/ST2 zu finden: Display/ Klassen, die automatisch die Einzelansichten von Sammlungen, Publikationen, Personen usw. in Datenblättern steuern. Zudem Klassen für Tabs (Kartei- reiter) und Schlagwortwolken Entity/ Alle Datenobjekte (Sammlungen, Publikationen, Personen usw.) sind als komplexe Entities mit zahlreich verknüpften "Feldern" unterschiedlichen Datentyps definiert. Die Klassen des Typs ST2_Entity_EntityAbstract sind in der Lage, diese komplexe Entities zu verwalten, inklusive der Sicherstellung von Konsistenz über multiple und verketteten Abhängigkeiten bei Relationen und Vokabularrelationen. Zudem verwalten sie auch spezielle Volltext-Suchindizes, die z.B die Suche nach Sammlungen powern. Besondere Datentypen sind: Vokabularfelder (Verwaltung im Rahmen komplexer Vokabulare wie Klassifikation oder Thesaurus), URLs (mit automatischer Überprüfung der URLs), Ereignisse. Es gibt keine 1:1 Abbildung Entity:Datenbanktabelle. Aufgrund der Vokabulare, der URLs, Ereignisse und Suchindizes verteilen sich die Daten einer Entity auf verschiedene Datenbanktabellen. Form/ Klassen zur halb-automatischen Steuerung von Formularansichten für die Datenbearbeitung Select/ Klassen für die komplexe, performante und zum Teil "intelligente" Suche nach Entities, sowohl Volltextsuche als auch kontrollierte Suche (Feldname/Feldwert) Text/ Klassen zur Bearbeitung von Text und User Input: Bereinigung "schmutzigen" User Inputs, Aufteilung einer Wortfolge in Einzelworte (Slice) und Abgleich mit einer "Stoppwortliste, usw. Transaction/ Klassen für die Durchführung von Datenbank-Transaktionen, insbesondere für Entities Vocab/ Klassen zur Verwaltung von Vokabularen. Ein Vokabular kann eine einfache Liste sein, oder per Zuschaltung von Relationsklassen (Helper) eine Klassifikation oder ein Thesaurus. Die Vokabularklassen sorgen bei Änderungen am Vokabularbestand für eine Synchronisierung mit den für die Entities gespeicherten Daten Wikipedia/ Klassen, die die Abfrage und interne Pflege von DBpedia Daten steuern Workflow/ Klassen zur Steuerung des User Workflows: Aktivitätsfeed, Link Checking und Logging Ausgabe: View ============= Während der Erledigung ihrer Aufgaben registrieren Front Controller und Action Controllers alle notwendigen Daten und Konfigurationen des aktuellen Requests in speziellen Eigenschaftsvariablen des View Objects. Als seine letzte Aktion gibt der Front Controller an das View Object die Anweisung, die HTML Ausgabe des aktuellen Requests vorzunehmen. Die View Schicht besteht aus zwei distinkten Ebenen, dem - Layout, welches die Seitenelemente ausgibt, die einigermaßen fest auf jeder Seite zu finden sind: HTML Head, Seitenkopf (mit Anwendungstitel und Suchbox) und der linken Leiste mit der Titelzeile, den dynamisch eingeblendeten Menüs und Boxen sowie den fest eingeblendeten Menüs "Datenbanken" und "Sammlungen Indizes"; sowie dem - View, das für jeden Request wechselnd für den eigentlichen Content Bereich verantwortlich ist. Die Ausgabe findet sowohl für Layout als auch für Views in so genannten Layout bzw. View Scripts statt, die sowohl statischen HTML und Javascript Code enthalten als auch aus den vom Controller konfigurierten Eigenschaften dynamisch die Daten formatieren und ausgeben. Dabei stehen den Scripts so genannten "View Helper" zur Verfügung (siehe unten). Layout Die Scripts für die Layout Ausgabe finden sich in /application/layouts/scripts layout.php Konfiguration der Seite: Meta Angaben, CSS Inclusion, Javascript (Script Inclusion und Head Script) page.php Eigentliches HTML Ausgabescript für die gesamte Seite. Weitere Layout Scripts sowie die Content Ausgabe des Views werden von hier aus delegiert headline.php Volldynamische Ausgabe der Titel- (und wenn gegeben) Infozeilen menus.php Volldynamische Ausgabe der unterschiedlichen kontextabhängigen Menüs und Boxen wie die Filterbox (beim Suchen nach Sammlungen), die Navigationsbox (beim Browsen durch eine Ergebnisliste nach einer Suche nach Sammlungen oder Publikationen) oder die Bearbeitungsboxen bei der Ansicht einzelner Entities nach Anmeldung am System menus/db.php & menus/sam_recherche.php Statische Menüs "Datenbanken" und "Sammlungen Indizes" |------------------------------------------------------------------------------| | HTML Head & Seitenkopf | | page.php | |------------------------------------------------------------------------------| | Titelzeile | Content View | | headline.php | | | | View Scripts: | | Menüs & Boxen | appliction/views/scripts/:controller/:action.php | | Dynamisch | | | menus.php | | | | | | "Datenbanken" | | | menus/db.php | | | | | | "Sammlungen Indizes" | | | menus/sam_recherche.php | | | | | |------------------------------------------------------------------------------| View Der für jedes Request anders aussehende Seitencontent - das View Object aus der Sicht der Anwendung - wird jeweils von einem Action-spezifischen View Script übernommen. Alle View Scripts befinden sich im Verzeichnis /application/views/scripts Ähnlich wie bei der Wahl von Controller und Controller Action (siehe oben) erfolgt die Wahl des View Scripts aufgrund der Route Parameter im Zusammenhang zur Request URL: - der erste URL Parameter (:controller) bezeichnet ein Verzeichnis in /scripts - der zweite URL Parameter (:action) bezeichnet das Script selbst in diesem Verzeichnis Beispiel: URL: {basispfad}/index/orte View Script Verzeichnis: /application/views/scripts/index View Script: /application/views/scripts/index/orte.php Ein View Script kann gewisse Teile seiner Ausgabe an Unterscripts delegieren. Dies erkennt man an View Helper Methoden wie: $this->render("pfad/zum/script.php"); $this->partial("pfad/zum/script.php",$daten); $this->partialLoop("pfad/zum/script.php",$daten); Der angegebene Pfad bezieht sich dabei relativ zum Verzeichnis für die View Scripts. Zu den Methoden selber vgl. Dokumentation Zend Framework: Zend_View. View Helper Zur Unterstützung der Ausgabe gibt es so genannte View Helper, die in eigenen Klassen definiert sind und als Methoden des View Objects (addressierbar per $this->helper() in einem View Script) zur Verfügung stehen (bei den Methoden im vorhergehenden Abschnitt handelt es sich um solche View Helper). Es gibt eine große Anzahl von View Helper des Zend Frameworks selber, insbesondere für die Ausgabe von Links, Menüs und Formularen (vgl. hierzu Dokumentation des Zend Frameworks: Zend_View). Zusätzlich kann man für spezifische Zwecke eigene Helper Klassen definieren und beim View Object registrieren lassen (die Registrierung erfolgt in Bootstrap.php mittels der Methode Bootstrap::_initViewConfiguration()). Diese Klassen enthalten eine Methode, die dem Klassenamen entspricht (minus Präfix) und dann als solche Methode vom View Object aufgerufen werden kann: Beispiel: Eigene Helper Präfix: ZX_ViewHelper (in Bootstrap.php gesetzt) Klasse: ZX_ViewHelper_SearchLink Methode: ZX_ViewHelper_SearchLink::searchLink(...) Aufruf innerhalb von Layout und View Scripts: $this->searchLink(...); Die speziell für diese Anwendung programmierten View Helper befinden sich im Verzeichnis /application/views/helpers Die Klassen haben das oben benannte Präfix. Die Dokumentation der View Helper findet sich unter Package "ZX_ViewHelper". 3. Kontakt ================================================================================ Autor von Anwendung und Dokumentation: Martin Stricker, Berlin martin.stricker@gmail.com http://strickr.de (c) Martin Stricker, 2009