Konzept

Das LIVESITE Programm ist eine Client Server Datenbank Anwendung.

Die grafische Ausgabe wird von HTML Generatoren erzeugt und entspricht damit nicht dem Gedanken 'quick & dirty' der ursprünglich von den Erfindern der PhP Programmiersprache für PhP Software vorgesehen war.

Entgegen dieser ursprünglichen Vorstellungen implementiert die Software stärker die, seit PhP 5 vorhandene Möglichkeit objektorientierter Strukturierung.
Die Einbindung der Klassen und Objekte der Software erfolgt sowohl 'byConvention' und 'byDeclaration'.
Entsprechend ihres Konzepts verwendet die Software HTML Templates überwiegend als minimales Gerüst in das generierter HTML Code eingefügt wird.

Als Kopierschutz verwendet die Software das Format und die spezifischen Konventionen des Quellcodes.

Modell und Struktur

Entsprechend des Konzepts der Generatoren, stellt sich der Durchfluss der Software so dar, dass die Geschäfts- und Präsentationslogik der Programme (Anwendungen) mit einem Stab implementiert wird, der an die allgemeine Programmschnittstelle angeschlossen ist.

Die allgemeine Steuerlogik ist dieser Schnittstelle vorgelagert und die allgemeine Präsentationslogik der Datenlieferung ist nach gelagert.
Die Software verwendet durchaus ein Modell, dass auf 'MCV' aufbaut, das aber dadurch, dass die Geschäfts- und Präsentationslogik der Anwendungen mit einem Stab implementiert ist, in zwei verschiedenen Objekträumen abgewickelt wird.
Für die Abwicklung verwenden die verschiedenen Prozesse gemeinsame Bibliotheken, Dienste und Speicherstellen, die mit einer API global bereitgestellt werden.
Für die Auslieferung der Daten werden die Ergebnisse der Prozesse abschließend zusammengeführt.

In diesem Modell empfangen Programme die Anfragen und Befehle der Benutzer über eine Schnittstelle und liefern ihre Resultate an die selbe Schnittstelle zurück.
Grafisch betrachtet zeigt sich ein Modell, das auf der Ebene des Programm Interface einen horizontalen Stab besitzt und vielleicht mit 'Model-Services-Controller' (MSC) bezeichnet werden könnte.

image

Thema und Inhalte

Ein Thema stellt die Verbindung zu einer Gruppe von Inhalten dar.
Die Themen des Content werden in einer Indexliste verzeichnet auf deren Einträge die Datensätze der Inhalte verweisen.
Auf den Indexeintrag eines Themas können sich beliebig viele Datensätze der Inhalten beziehen.
Die Themen selbst sind wiederum Kapiteln zugeordnet und die Kapitel steuern das Template mit dem das Dokument angezeigt wird.
Das bedeutet: Die Angabe eines Themas steuert die optische Erscheinung des Dokuments.
Bei den Inhalten selbst handelt es sich um Datenobjekte, die ihre Daten aus weiteren relational verbundenen Datenbeständen beziehen.

Inhalte

Als 'Inhalte' werden die Nutzdaten des Dokuments bezeichnet.
Das Template, sowie Menüs und andere Elementgruppen, werden nicht als 'Inhalte' des Dokuments angesehen, sondern das Template wird als der 'Rahmen' des Dokuments und beispielsweise die Menüs werden als Insertionen betrachtet.
Insertionen in den Rahmen des Template werden als 'Intarsien' bezeichnet.
Der Produzent des Template ist ein Unterobjekt des Produzenten des Dokuments. In der API ist es über das 'Document' Objekt erreichbar.
'Menus' dagegen ist ein direktes Kind des API Objekts.

Nutzdaten, Formatierung

Die Software vermeidet grundsätzlich die Speicherung von HTML Code in der Datenbank.
In die Datenbank gelangen ausschließlich Nutzdaten die nicht als Steuerzeichen interpretiert werden können.

Dort wo Steuerdaten in der Datenbank abgelegt werden müssen, werden Diese durch, dem System wohl bekannte, Masken ersetzt.

Die Software verzichtet prinzipiell auf den Einsatz Skript basierter HTML Editoren für die Formatierung von Nutzdaten.

Dienste, Anwendungen und Module

Die Software ist modular aufgebaut und gliedert seine Programme in 'Dienste' und 'Anwendungen'.
Als Dienste werden alle Funktionsgruppen bezeichnet, die ein ständiger Bestandteil der Software sind und für Programme der Anwendungen bereitstehen.
Die Software implementiert Dienste und Anwendungen möglichst gekapselt als gesonderte Module. Anwendungen entsprechen nach Möglichkeit immer einem Modul.
LIVESITE ist dafür ausgelegt für jede Anfrage des Klienten immer nur eine Anwendung (Modul) und ein Thema zu betreiben.
Das bedeutet, das jede Anfrage immer gezielt an ein Modul gerichtet ist.
Von welchem Modul eine Clientanfrage bedient werden soll, bezeichnet die vom Klienten eingehende Exekutive der Serveranfrage.

Der Übergang von Modulen die reine Dienste oder reine Anwendungen bereitstellen ist fließend und verläuft in drei Stufen:

  • Kernelmodule,
  • Programmierbare Module,
  • Erweiterungsmodule.

Die Module unterscheiden sich durch ihre Anbindung an dynamische Umgebungsvariablen:

  • Kernelmodule verlaufen in der Umgebung von System Variablen. Sie verwenden ausschließlich Funktionen der internen Programmbibliotheken, oder anderer Kernelmodule, und stellen ihre Bibliotheken anderen Diensten und Anwendungen bereit.
  • Programmierbare Module erstellen ihre Produkte in einer Umgebung flexibler Steuerdaten, die für jedes davon abgeleitete Objekt eingestellt werden können. Sowohl Erweiterungsmodule, wie auch Kernelmodule können programmierbar sein.
  • Erweiterungsmodule verwenden ausschließlich eigene Programme und Dienste der Kernelmodule für ihre Anwendungen. Sie stellen der übrigen Software keine Dienste bereit und können deshalb wahlfrei in die Software eingebunden oder aus der Software entfernt werden.

Allgemeine Programmschnittstelle (Dispatch)

Die Allgemeine Programmschnittstelle stellt die Verzweigung vom Hauptprogramm in die Programme der Module und dadurch auch in die Produktion des Content bereit.

Die Allgemeinen Programmschnittstelle prüft die Befehlsdirektive der Anfrage, liest die Deklarationsdateien der Module aus, stellt entsprechend der darin gefundenen Vorgaben Laufzeitvariable ein, und leitet die Anfrage des Klienten an die Methode des Programmcontrollers weiter, der mit der eingehenden Exekutive bezeichnet ist.

Das Ergebnis jedes Programmaufrufs ist grundsätzlich immer entweder HTML Code oder ein Signal, das über eine Umleitung die Produktion von HTML Code veranlasst.

Schnittstellen (Interface)

Die 'Interfaces' der Software entsprechen nicht dem Konstrukt, das von PhP als 'Interface' definiert wird, sondern stellen selbständige Programme dar.
Die meisten dieser Schnittstellen besitzen, neben privaten und öffentlichen Eigenschaften zur Übergabe von Werten, auch Methoden zur Prüfung, Auswertung oder Vorverarbeitung ihnen zugewiesener Werte.

Programmcontroller

Die Programmcontroller sind Teil der Module und definieren die Methoden, die der Klient mit der versendeten Exekutive aufruft. Die Methoden der Programmcontroller führen Prüfungen aus und starten die vom Klienten angeforderten Programme.
Die einzelnen Methoden der Controller ermöglichen die Ausführung jeweils eines Programms oder Prozesses.
Das Ergebnis der Prozesse ist für jede Anfrage grundsätzlich immer ein Signal oder Code. Besteht das Resultat eines Programms aus einem Signal, dann bezeichnet das Signal den Durchlauf einer Umleitung, die den erforderlichen Code nach einem neuerlichen Durchlauf liefert.
(Näheres siehe Kapitel 'Allgemeine Programmschnittstelle')

Programmierschnittstelle (API)

Das Objekt 'Application' bildet eine globale Programmierschnittstelle für den Zugriff auf die Dienste der Software und stellt der Laufzeitumgebung der Software die in ihren Objekten eingerichteten Speicherstellen bereit.
Die Programme der Module bedienen sich hauptsächlich der Methoden, die von globalen Objekten der API bereitgestellt werden.
Die Organisation der API Objekte richtet sich an dem Anwendungszweck der darin eingebundenen Funktionsgruppen und definiert so die Systemdienste der Software.
Darunter sind auszugsweise: Session, Request, Database, Modules,...etc.

Tabellencontroller

Die Klassendateien der Tabellencontroller definieren abstrakte und spezifische Methoden für den Zugriff auf die, von der Software verwalteten, Datenbanktabellen.
Sie vermitteln die Befehle der Programme an die abstrakte Datenbankschnittstelle.
Für jede Datenbanktabelle ist jeweils ein Controller definiert.

Deklarationsdatei der Module

Jedes Modul verfügt über eine Deklarationsdatei in der, neben den Direktiven für die Clientanfrage auch, die Controllerdatei des jeweiligen Moduls bezeichnet ist.
Entsprechend der Deklarationen dieser Datei veranlasst die Allgemeine Programmschnittstelle die Einbindung der erforderlichen Module, Controller oder Formulare und ruft die, der Clientanfrage entsprechenden, Methoden der Programmcontroller auf.

Formulare

Formulare im Sinne von LIVESITE haben wenig Ähnlichkeit mit HTML Formularen, außer dass ihre Produkte HTML Formulare enthalten.
Es handelt sich um Produzenten von HTML Code, der im Browser des Klienten versandfähige Eingabemöglichkeiten bereitstellt.
Ein LIVESITE Formular kann ein einzelnes, mehrere oder auch keine HTML Formulare enthalten.
Auch wenn ein LIVESITE Formular kein HTML Formular Element enthält, kann es Daten an den Server versenden.
Im letzten Fall erfolgt der Versand immer über das Javaskript des Client.

Produkt

Ist von dem 'Produkt' eines Programms die Rede, dann ist damit immer HTML Code gemeint.
Der Code wird von Erzeugern hergestellt, von Produzenten weiterverarbeitet und als Produkt ausgeliefert oder bereitgestellt.

Beispielsweise betreiben folgende Objekte des Kernel Produzenten:

  • Template,
  • Content (kann Formulare anzeigen),
  • Formular (in drei Typen: Selektor, Editor, Dialog),
  • Tabelle,
  • Menü.

Puffer, Speicher (Ausgabe)

Für die Weitergabe von HTML Produkten und Steuerwerten verwenden die Prozesse des Kernels Puffer und Speicher.

Die wichtigsten globalen Speicher werden verwendet für:

  • Request (Eingangswerte – Puffer),
  • Session (Benutzersitzung – persistenter Speicher),
  • AJAX, Content, Response (Rückgabe der Controller – Ausgabepuffer),
  • Auflistung zur Erkennung von Zugriffsrechten eingehender Exekutive.

Die Prozessoren und Produzenten des Template verwenden lokale Speicher für:

  • Request (Eingangswerte – Puffer),

Generatoren, Erzeuger und Produzenten

Die Software betreibt für die Produktion der HTML Ausgabe eine Reihe von 'Erzeugern' und 'Produzenten', die ihre Produkte mit einer fein gegliederten Struktur von HTML Attributen auszeichnen.
Die ausgegebenen Dokumente werden dynamisch mit CSS Regeln und Skripten verbunden.
Als 'Erzeuger' werden Funktionsgruppen bezeichnet, die ausschließlich Code generieren.
Als 'Produzenten' werden Funktionsgruppen bezeichnet, die sowohl selbst Code erzeugen, wie auch den Code fremder Erzeuger einbeziehen und als Produkt ausliefern oder bereitstellen.
Die Auslieferung erfolgt entweder als Rückgabewert oder als Ablage in einer der Software wohl bekannten globalen/regionalen Speicherstelle. Erfolgt die Übergabe als Bereitstellung, dann wird der Wert in einer lokalen Speicherstelle abgelegt.

Eingangsdaten

Der Apache Server ist über eine HTACCESS Datei so eingestellt, dass er keine Daten akzeptiert, die als Parameter dem URI bei ihm eingehen.
Jeglicher Eingang wird grundsätzlich an die Startdatei der Software weitergegeben.
Ausnahmen davon sind Anfragen nach Bild-, CSS oder Javaskript Dateien.
Der eingehende URI wird von der LIVESITE Software ausgewertet wobei das letzte Glied des URI als Exekutive der Software interpretiert wird.
Wird bei der Analyse festgestellt, dass die Exekutive den Namen einer existierenden Datei oder eines existierenden Verzeichnisses trägt, dann wird die eingehende Anfrage auf die Startseite umgeleitet.

Templates

Die Templates der Dokumente erreichen in der LIVESITE Software nicht die selbe Bedeutung, wie es für PhP gestützte Software vorgesehen ist.
Sie dienen hier lediglich als Grundgerüst für die Einbindung von HTML Produkten die von den Produzenten der Software bereitgestellt wurden. Ihre Struktur ist so flach wie möglich gehalten.
Es handelt sich um einfache Bäume von HTML Elementen, die mit wohl bekannten xml conformen Ersetzungsmarken versehen sind.
Eine direkte Einbindung von PhP Skripten in den Code der Templates ist nicht vorgesehen.

Dokument und Ansichten

Es wird zwischen Ansichten und Dokument unterschieden.
Ist von Ansichten die Rede, dann ist die damit ausschließlich die Grafik gemeint.
Mit 'Dokument' ist immer die Ansicht mit dem DOM einer HTML Seite gemeint.
Ansichten und Dokumente werden dann als 'Benutzerschnittstelle' bezeichnet, wenn sie interaktive Elemente enthalten.

Frontend und Backend

Als Frontend oder Backend werden Variationen der Benutzeroberfläche bezeichnet, die entsprechend der Autorisierung der Benutzersitzung Zugriffe auf bestimmte Bedienelemente der Software Administration zulassen oder unterbinden.
Die Benutzeroberfläche wird immer mit dem Template angezeigt, dass bei Start der Produktion des Dokuments in der Dokumenten Schnittstelle deklariert ist.
Die reguläre Deklaration des Template erfolgt in zwei Schritten:

  • Initial wird das Template im Verteiler der allgemeinen Programmschnittstelle deklariert. Dort wird vorerst der entsprechende Wert aus der Deklarationsdatei für die Deklaration verwendet.
  • Werden Inhalte des Content angefordert, wird der Wert für das Template nachträglich überschrieben. Dazu verwendet das Programm das Template, das für das Kapitel des aufgerufenen Themas deklariert wurde.

Die Deklaration des Template in 'DocFace' kann zusätzlich auch an anderer Stelle überschrieben werden. Entscheidend ist, dass es vor dem Start der Produktion des Dokuments deklariert wurde.

Javascript

LIVESITE Formulare, Editoren und Menüs verwenden Javascript.
Fast alle Formulare, Dialoge und Editoren versenden ihre Serveranfragen via Javascript an den Server.
Ohne Javascript ist der Betrieb einer LIVESITE Internetseite nicht möglich.
Jedes Formularobjekt verfügt über ein gleichnamiges Javascript das die Handlungen des Benutzers unterstützt. Diese Unterstützung dient vorwiegend dem Versand der Formulardaten, wird aber auch für Animationen, verschiedene Automatismen, und vor Allem auch für Datendienste verwendet, die mittels AJAX angefordert werden.
Per XMLHttp ausgelieferte Daten werden besonders häufig für die Anzeige von Dialogen, die kontextsensitive Beschaffung und Prüfung von Daten, oder verschiedene Serverdienste wie das Sessionpolling und Statusberichte genutzt.

Schichten des Programmdurchlaufs

Jeder Aufruf des Clients an den Servers erzeugt einen Rücklauf von Daten zum Client. Dabei durchlaufen die Prozesse folgende Schichten:

  • 1) Request (Receiver)
  • 2) Session (Benutzerautorisierung, Zustände)
  • 3) Allgemeine Programmschnittstelle (Auswertung der Executive und Ausführung der Programme)
  • 4) Produktion des Dokuments (Template/Document)
  • 5) Response (Ausgabe)

Binder

Die Software verwendet verschiedene Dateien und Klassen, in denen sie Binder für die Implementation von Klassendateien oder Speicherstellen definiert.
Binder implementieren Klassendateien, erstellen Instanzen der darin definierten Objekte, und definieren Speicherstellen oder Konstanten.
Der initiale Binder der Software ist in der Datei '/inc/require.php' definiert.
Dort werden die grundlegenden Objekte und Konstanten für die Laufzeitumgebung der Software definiert und eingerichtet.
Zu seiner Aufgabe gehört es auch, eine Instanz des API Objekts zu erstellen, wobei der wesentliche Teil der initialen Bindungen ausgeführt wird.
Stellen Klassen keine globalen Dienste bereit, werden sie nicht von der API, sondern von dem Objekt implementiert, die ihre Methoden benötigt.