Grundlagen

1. Einführung

• Model-View-Controller-Pattern:
  Das Model-View-Controller-Pattern ist ein Pattern der Präsentations-Schicht. Es zielt darauf ab ein flexibles Programmdesign zu generieren. Insbesondere diktiert es eine strikte Trennung der Bereiche Model, View und Controller. Damit wird die Anwendung für spätere Änderungen einfach pfleg- und erweiterbar. Zudem reduziert sich die Komplexität der einzelnen Komponenten und einzelne Softwareteile werden wiederverwendbar.
  Das Modell enthält dabei die darzustellenden Daten oder Informationen über das Verhalten der Software. Der View beschreibt die Art der Darstellung und wird in der Regel durch Template-Dateien repräsentiert. Der Controller kennt sowohl das Model als auch den View und kann durch Kenntnis dieser den View mit den gewünschten Daten aufbauen.
  
  Siehe hierzu auch http://de.wikipedia.org/wiki/MVC.
  
  
• Composite-Pattern:
  Die Objekte der Präsentations-Schicht sind alle vom zentralen Objekt coreObject, bzw. vom Objekt Document abgeleitet. Auf Grund dieser Tatsache können beliebige Objekte, die von Document erben in den Objektbaum einer Seite eingehängt werden. So kann die Präsentations-Schicht um beliebige Elemente auf einfache Art und Weise erweitert werden.
  
  Siehe hierzu auch http://en.wikipedia.org/wiki/Composite_pattern.
  
  
• 3-Schicht-Architektur:
  Wie bereits angesprochen, unterstützt das Framework die Implementierung von Applikationen in der 3-Schicht-Architektur. Diese sieht vor, dass Anwendungen in die Schichten Präsentation, Geschäfts-Logik und Daten-Schicht unterteilt sind die alle für sich genommen eine bestimmte Funktionalität kapseln. Die Präsentations-Schicht - oder kurz genannt "pres" - ist für die Darstellung der Applikation in einer (HTML-)GUI zuständig. Sie kennt alle HTML-Elemente und ebenso die Business-Schicht (biz), die der Präsentations-Schicht Daten und Informationen zur Art und Inhalt der Darstellung liefert. Innerhalb der biz-Schicht werden die Geschäftsprozesse der Anwendung gekapselt und ausgeführt. Die Datenschicht beschäftigt sich einzig und allein mit der Daten-Accquise und -Persistenz. Hierzu kennt sie die Datenquelle und hat Tools zur Verfügung mit denen aus der Datenquelle gelesen werden kann.
  
  
• Domain-Object-Pattern:
  Das Domain-Object-Pattern beschreibt, dass Daten, die in einer Anwendung verarbeitet werden in dedizierten Daten-Objekten gehalten werden. Das Pattern wird in der Regel in Verbindung mit dem Data-Mapper-Pattern verwendet. Die Kommunikations-Objekte zwischen den oben ganannten Schichten sollte immer das Domain-Object sein. Ein "Domain-Object" kann in der realen Anwendung auch eine Liste von Domain-Objekten oder ein Baum von unterschiedlichen Domain-Objekten sein. Die Ausprägung ist abhängig von der Anwendung.
  
  
• Data-Mapper-Pattern:
  Ein Data-Mapper ist per se ein "Übersetzer". Er Übersetzt das Datenmodell der Datenbank in das Datenmodell der Applikation. Diese müssen nicht zwangsläufig übereinstimmen und tun es in vielen Anwendungsfällen auch nicht. Beispiel: In einer Anwendung werden Personen und deren Adressen verwaltet. Das Datenmodell hat für das Objekt "Person" und das Objekt "Adresse" je eine eigene Tabelle. Um die Zugehörigkeit zwischen den beiden Objekten abbilden zu können existiert eine dritte Tabelle - die Beziehungstabelle. Möchte die Anwendung nun das Objekt "Person" mit seiner Adresse laden, so muss der Data-Mapper zuerst die Person und danach anhand der Beziehung die Adresse zum Objekt hinzuladen. Beim Speichern des Objekts Person geht der Data-Mapper den Weg umgekehrt und persistiert jeweils Adresse und anschließend die Daten des Objekts "Person".
  
  

2. Aufbau und Bedeutung der Ordner-Struktur

apps/ (Verzeichnis alle Quellcode-Dateien)
     [config/ (Verzeichnis für Konfigurationsdateien)]

     core/ (Verzeichnis für die Core-Komponenten)
          benchmark/
          configuration/
          database/
          errorhandler/
          filesystem/
          filter/
          frontcontroller/
          logging/
          pagecontroller/
          service/
          session/
          singleton/

     modules/ (Verzeichnis für die Module)
             comments/
             guestbook/
             kontakt4/
             pager/
             socialbookmark/

     [sites/ (Verzeichnis für Webseitendateien)]

     tools/ (Verzeichnis für die Tools-Komponenten)
           cache/
           datetime/
           form/
                taglib/
           html/
                taglib/
           image/
           link/
           mail/
           string/
           validator/
           variablen/

3. Aufbau einer einfachen Applikation

3.1. Aufbau einer index.php

• {1}: Name der Webseite. Dieser Name betitelt lediglich den Namen des Objekts "Page" und wird nicht zur Anzeige gebracht. Das Argument ist zudem optional.
• {2}: Namespace zum Basis-Template bzw. Context. Um ein Design laden zu können sind die Angaben "Namespace" bzw. "Pfad" und "Designname" notwendig. Der erste Teil ("Namespace" bzw. "Pfad") wird zugleich als Context für Konfigurationsbelange eingesetzt (siehe hierzu Konfiguration).
• {3}: Name des Basis-Templates. Hier kann entweder der Name des Basis-Templates ohne dessen Endung oder ein Sub-Pfad incl. Name des Basis-Templates ohne Endung angegeben werden.

3.2. Aufbau des Basis-Templates

<html>
<head>
  <title>Demo</title>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
...
</body>
</html>

3.3. Basis-Konfiguration

• Environment: (verwendet von: configurationManager, MySQLxHandler, MySQLHandler, SQLiteHandler, ...)
  
  Jede Konfigurations-Datei besteht aus vier unterschiedlichen Bestandteilen:
  
  
  • Namespace: Ordner, unterhalb dem alle Konfigurationsdateien dieser Anwendung liegen
  • Context: Aktueller Context der Applikation
  • Umgebung: z.B. für Entwicklung, Test und Live
  • Dateinamen: Dateiname der Konfigurationsdatei
  
  Diese Abstraktion wurde eingeführt, damit eine Anwendung oder ein Modul in unterschiedliche andere Anwendungen oder Module eingebunden werden kann und auf unterschiedlichen Systemen zur gleichen Zeit ohne Änderung des Quellcodes lauffähig ist. Für das Laden von Konfigurationen gibt es jedoch standardisierte Methoden, so dass sich der Programmierer darum nicht mehr kümmern muss. Weiterführendes dazu kann im Kapitel Konfiguration nachgelesen werden.
  
  Standard-Wert: "DEFAULT"
  
  
  
• URLBasePath: (verwendet von: bbCodeParser, socialBookmarkManager, Suche, ...)
  
  Viele Module verlinken auf sich selbst oder ander Bereiche eines Moduls oder einer Webseite. Aus diesem Grund muss bekannt sein, wie die Basis-URL der Seite lautet. Der Registry-Wert URLBasePath definiert diese.
  
  Standard-Wert: "HTTP_HOST-Wert des $_SERVER-Arrays"
  
  
  
• URLRewriting: (verwendet von: PageController, FrontController, linkHandler, frontcontrollerLinkHandler, ...)
  
  Der vorliegende PageController unterstützt URL-Rewriting. Unter URL-Rewriting versteht der Autor die Verwendung von URLs der Form http://www.domain.tld/param1/value1/param2/value2 statt http://www.domain.tld?param1=value1&param2=value2. Ist der Wert auf "true" gesetzt, so werden die mit den linkHandler und frontcontrollerLinkHandler generierten Links in der rewriteten Form ausgegeben.
  
  Standard-Wert: "false"
  
  
  
• LogDir: (verwendet von: Logger, ...)
  
  Um zentrales Logging zu ermöglichen, muss der Pfad, in den Log-Dateien geschreiben werden zentral bekannt gegeben werden. Der Pfad wird von der Klasse Logger verwendet.
  
  Standard-Wert: "./logs"
  
  
  
• LibPath: (verwendet von: bbCodeParser, ...)
  
  Die Direktive LibPath speichert den Basis-Pfad, in dem die Programmdateien abgelegt wurden. Der Pfad wird dynamisch gesetzt und ist nur für den lesenden Zugriff freigegeben.
  
  

Kommentare