Arbeitsweise

Bei dbXwebApp wird immer nur eine einzige PHP Datei aufgerufen. Diese Datei (dbxWebApp.php) inkludiert nur bei Bedarf die Module, die für die aktuelle Anfrage benötigt werden. Dadurch ist das ausführende PHP Script immer nur so groß wie nötig und immer so schnell wie möglich.

dbXwebApp ist komplett modular und überwiegent objektorientiert. Jeglicher Inhalt ist konsequent vom Design entkoppelt.
Alle Ausgaben können vom System gecached werden. Das Caching arbeitet dabei weitgehend vollautomatisch.

Bei jedem Modul kann individuell festgelegt werden, ob es cachebar ist. Ausgaben können auch gemischt aus Inhalten vom Cache und neuen dynamisch erzeugten Inhalten bestehen. Einzelne Funktionen (z.B das Zählen von Seitenaufrufen) lassen sich, auch für Inhalte die aus dem Cache kommen, erneut ausführen.

FCA (full cache able) Seiten werden sogar ganz ohne einen einzigen Datenbank Zugriff aus dem HTML-Cache innerhalb weniger tausendstel Sekunden ausgegeben.

Zu den besonderen Fähigkeiten von dbXwebApp gehört die Nutzung von eigenen DataDictionarys für jede db-Tabelle. In diesen DataDictionarys werden die Zugriffsberechtigungen und die grundsätzlichen Formatierungs- und Validierungs-Regeln festgelegt. Dabei ist es möglich automatische Funktionen und Berechtigungen bis hin zur Feldebene zu definieren. Auch sorgen die DataDictionarys für die Datenintegrität, insbesondere bei relational verknüpften Tabellen.

Das System hat eine ausgeklügelte Logik um Parameter als URL an das System weiterzugeben. Alle URLs werde dabei automatisch um benötigte Werte ergänzt. Bei jedem Aufruf werden unnötige oder doppelte Parameter vom System entfernt. dbXwebApp arbeitet dabei mit sogenannten Suchmaschienen freundlichen URLs.

Jeder Aufruf lädt immer ein Design-Template in dem belibieg viele Modulaufrufe stehen können. Jedes Modul kann auch wieder weitere Module an beliebiger Stelle aufrufen. Jedes Modul kann beliebig viele Templates und weitere Modulaufrufe beinhalten.

Modulaufrufe werden jeweils mit der Ausgabe (content) des jeweiligen Modules ersetzt. Jedes Design Template kann einen Platzhalter haben, der durch die Ausgabe eines über die URL oder auch POST-Variablen definierten Modules ersetzt wird.

Die Steuerung der einzelnen Module unterliegt einer einfachen und effektiven Logik. Alle Module können auch mehrfach eingebunden werden und mit jeweils eigenen Parametern gesteuert werden. Dabei kann auf einfache Weise festgelegt werden welche Parameter dabei statisch und welche Parameter durch entsprechende Aufrufe dynamisch änderbar sind.

Das System verfügt über eine sehr umfangreiche Rechteverwaltung.

Alle Module lassen sich einfach erweitern. Auch das Erstellen eigener Module ist sehr einfach. dbXwebApp nimmt dabei durch seine automatischen Funktionen und durch die Einheitliche Administration von Modulen Ihnen viel Arbeit ab.

Das Daten-Handling unterscheidet sich auch von allen anderen System. Innerhalb von dbXwebApp sind auch komplizierte Auswertungen und Listen durch sehr einfache SQL Befehle möglich. Nahezu alle SQL-Anweisungen laufen dabei über die intrigierten DataDictionarys.

1. An das Script können beliebig viele Parameter mit übergeben werden.
   www.domain.de/dbXwebApp.php/parameter1/wert1/parameter2/wert2/parameter3/wert3 ...
   Wahlweise können die URL-Parameter auch mit dbXwebApp.php?parameter1=wert1¶meter2=wert2 übergeben werden. Wenn das Script ohne den Parameter dbx_modul aufgerufen wird, dann wird automatisch das Modul dbx_home aktiviert.
   .
2. Das System überprüft ob es die Aufgerufene Seite ganz oder teilweise aus dem HTML oder db-Cache bereitstellen kann.
   Bei Seiten aus dem HTML-Cache wird der Content unmittelbar nach Einmischen einiger wenigen CMS-Daten an den Web-Server übergeben.
   .
3. Das System lädt je nach activen Modul oder expliziet durch den Parameter dbx_template/template_name ein Design Template
   Das jeweilige Design-Template kommt aus dem Ordner /design/'name'/ und ist eine vollwertige HTML-Seite mit haed und body.
   .
4. Das jeweilige Design-Template kann belibig viele Modulaufrufe und den Platzhalter für das über Paramter aktivierte Modul beinhalten.
   Das Design-Template legt den grundsätzlichen Aufbau der Ausgabe fest. Nicht den Inhalt, der kommt aus den Modulen.
   .
5. Falls über die URL ein Modul aktiviert wurde wird der Platzhalter {modul_content} durch die Ausgabe des aktiven Moduls ersetzt.
   z.B. dbxWebApp.php/dbx_modul/dbx_user/op/adress/dbx_template/dbx_mywebapp Das System läd das Design Template dbx_mywebapp.htm und ersetzt darin den Platzhalter mit der Ausgabe vom Modul dbx_user.
   
   Das Modul dbx_user wertet den Parameter op aus und ruft die entsprechende Funktion auf. Diese Funktion gibt an das System einen Inhalt zurück. In diesem Beispiel ein Eingabeformular mit den Adress-Daten des jeweiligen Benutzers.
   .
6. Das System interpretiert das Design-Template und ersetzt alle Modulaufrufe mit deren jeweiligen Modulausgaben.
   Alle Modul und Funktionsaufrufe innerhalb von Templates stehen immer in eckigen Klammern
   [modul=modul_name]para1=a¶2=b[/modul]
   Jedes Modul kann auch wieder beliebig viele Modulaufrufe innerhalb seines Rückgabe-Contens stehen haben.
   .
7. Das System übergibt an den Web-Server die komplette Ausgabeseite.
   Der Web-Server überträgt die Seite über das Intra- oder Internet zum Internet-Browser. Seiten, die aus dem FCA Cache kommen, werden innerhalb weniger tausendstel Sekunden ausgeliefert.
   .
8. Falls das Caching activ ist wird der Cache wenn nötig automatisch aktualisiert.
   Bei FCA-Seiten wird der HTML-Cache falls nicht vorhanden erstellt.