UNB Components (UNB2)

Diesmal gab es einige Fehlerkorrekturen, kleine Performance-Verbesserungen und auch ein paar neue Funktionen. Der Genehmigungsprozess für Dateien wurde vereinfacht, die Lokalisierung der Oberfläche ist begonnen und einzelne Teile der Demo-Anwendung sind zur besseren Übersicht selbiger in die UNB-Klassen gewandert. Details sind der Datei CHANGES.txt zu entnehmen. Die Datenbankstruktur wurde nicht geändert, wohl aber stellenweise ihr Inhalt. Es wird jetzt PHP-Version 5.3 vorausgesetzt. Diese Version sollte mit SQLite und MySQL funktionieren, andere Datenbanken sind ungetestet.

Da ich nun einen weiteren Anwendungsfall für UNB Components gefunden habe, habe ich die Arbeit daran wieder höher priorisiert und in den freien Tagen um Neujahr ein paar Änderungen vorgenommen. Die betreffen zunächst überwiegend die Stabilität und Portabilität der Basisklassen bzgl. der Datenbankfunktionen. In den letzten Tagen sind dann noch einige Änderungen dazugekommen. So werden in der Demo-Anwendung jetzt wie in einem Forum mehrere aufeinanderfolgende Mitteilungen auf einer Seite angezeigt. Mitteilungen können als Entwurf gespeichert und mehrere Dateien hinzugefügt und in den Text eingebunden werden. Alle Änderungen werden in der Datei CHANGES.txt protokolliert. Diese Version ist noch wenig getestet und es gibt noch einige Aufgaben in nächster Zeit zu erledigen. Ein paar der nächsten großen Themen umfassen Lokalisierung und die Textsuchfunktion.

Über vier Jahre nach der ersten öffentlichen Ankündigung des Projekts und nach gelegentlichen Anfragen einzelner Interessierter habe ich mich nun dazu entschlossen, die aktuellen Arbeitsergebnisse zu veröffentlichen. Das System ist zwar bei weitem noch nicht fertig, aber die Dokumentation ist seit Anfang an dabei, um anderen die Hintergründe zu erklären, und am Beispiel meines Web-Fotoalbums kann man doch sehen, dass man durchaus schon was mit der aktuellen UNB2-Version anfangen kann. Im Folgenden ist die Verzeichnisstruktur des Archivs beschrieben:

• demo_app/ – Beispielanwendung
  • img/ – Bild-Ressourcen der Beispielanwendung
  • _{foot,head}.inc.php – Kopf- und Fußzeile der Seiten. In _head.inc.php wird das UNB-Framework initialisiert.
  • dynamic-complete.js – dynamic-lib-JavaScript-Bibliothek
  • xml{form,server}.php – Demo der XML-Schnittstelle
• doc/ – Dokumentation
  • code_reference/ – Generierte Quelltextreferenz mit allen Klassen und Methoden (wird mit tools/codedoc.php erstellt)
  • *.pdf – Entwicklerdokumentation, enthält eine ausführliche Projektbeschreibung, Modelldiagramme und Referenzen
• sql_setup/ – Installationsskripte zur Datenbankeinrichtung
• tools/ – Hilfsprogramme zum Generieren der Quelltextreferenz und zum Komprimieren der Klassendateien
• unb_lib/ – UNB2-Klassendateien
  • captcha_*.txt – Wortlisten zur Prüfbildgenerierung (CAPTCHA)
  • unb_all.lib.php – Komprimierte UNB2-Bibliothek, enthält alle Klassen ohne Kommentare, Leerzeilen usw., für höhere Ausführungsgeschwindigkeit (wird mit tools/compress.php aus den anderen .php-Dateien erstellt)
  • *.ttf – Schriftdateien zur Prüfbildgenerierung (CAPTCHA)
• unb2test.db – Leere SQLite-Datenbank mit eingerichtetem Schema
• unb_config.inc.php – Konfigurationsdatei, wird vom Setup und der Beispielanwendung verwendet
• unb_setup.php – Richtet Systembenutzer in einem leeren Datenbankschema ein, um die Verwendung der Anwendung zu ermöglichen

Die Projektsprache ist ausschließlich deutsch, d. h. jegliche Dokumentation ist in deutscher Sprache verfasst. Die Quelltextdokumentation ist dagegen in englischer Sprache verfasst, ebenso wie die Beispielanwendung. Es ist geplant, die Dokumentation zumindest teilweise auch ins Englische zu übersetzen. Eine Übersetzung der Beispielanwendung bietet ein Betätigungsfeld für die Implementierung von i18n.

Fortschritt der Implementierung:

Nach zeitweise langer Pause und sehr geringem Fortschritt der Arbeiten ging es in den letzten Wochen wieder bedeutend schneller voran. Die Basisklassen wurden teilweise überarbeitet und die Code-Architektur verbessert. Es sind außerdem neue Klassen dazugekommen, die HTML-Formulare automatisch verarbeiten und HTML-Formularelemente ausgeben. Dadurch beschränkt sich der Aufwand, eine UNB-basierte Anwendung zu schreiben, gemäß der ursprünglichen Zielsetzung auf wenige Aufrufe zum Einbinden der Bibliothek, Initialisieren und Verarbeiten der Eingaben. Die restliche Seite wird im HTML-Code erstellt und an den Stellen, an denen UNB-Elemente erscheinen sollen, genügt oft ein einziger Methodenaufruf der statischen UnbUi-Klasse. Etwas Logik ist natürlich auch hier noch erforderlich, um sinnvolle Inhalte anzuzeigen. Man muss sich an dieser Stelle aber nicht mehr um technische Details wie Feldnamen, Werterhaltung der Eingabefelder oder den gesamten Ablauf der Formularverarbeitung samt Datenprüfung kümmern. Außerdem ist die implizite Registrierung fertiggestellt. Damit kann man eine Mitteilung schreiben, ohne einen Account zu besitzen. Es ist nur die Angabe des Namens notwendig. Dabei wird automatisch ein Account angelegt und ein Authentifizierungs-Cookie im Browser abgelegt. Damit ist man ganz normal angemeldet und hat vollen Zugriff auf seine Mitteilungen und alle Benutzerfunktionen. Bei Bedarf können Anmeldename und -kennwort vergeben werden, um den neuen Account auch von anderen PCs/Browsern aus zu verwenden.

In diesem Rahmen ist auch eine neue Demo-Anwendung entstanden, die einem Webforum schon wesentlich näher kommt. Die aktuelle Entwicklung findet in dieser Oberfläche statt, die möglicherweise später auch als Beispiel-Anwendung veröffentlicht wird.

Momentan bin ich dabei, die neue UNB-Funktionalität in mein Web-Fotoalbum zu integrieren, um das Kommentieren von Fotos zu ermöglichen. Das Fotoalbum basiert bereits von Anfang an auf UNB2 und verwendet Attachments von Mitteilungen und (unsichtbare) Tags.

Der gesamte Code der UNB2-Klassen umfasst derzeit effektiv ca. 6 100 Codezeilen und (komprimiert) knapp 250 KiB. Das macht seit November 2007 fast eine Verdopplung des Code-Umfangs.

Der Kompatibilitätstest mit Oracle muss irgendwann wiederholt werden, da beim letzten Mal anscheinend etwas schief gelaufen ist. Das hat aber keine hohe Priorität, da ich nicht davon ausgehe, dass irgendjemand Oracle für Webanwendungen in dieser Größenordnung einsetzt.

Datenbankunterstützung:

Der Oracle-Datenbankserver wird voraussichtlich erstmal nicht unterstützt, da es damit nicht möglich ist, portablen Code zum Erzeugen von neuen Primärschlüsseln zu verwenden. Weder SELECT ... FOR UPDATE noch LOCK TABLE werden ausreichend unterstützt. Mit der angestrebten Datenbankkompatibilität auf ANSI-SQL-Ebene wird es also leider nichts, weil alle bekannten Systeme (IBM DB2 ist weiterhin ungetestet) nicht ausreichend kompatibel zueinander sind. Bleiben vorerst also nur MySQL und SQLite übrig. PostgreSQL erfordert eine separate Version großer Abfrageausdrücke, Oracle erfordert die Verwendung von Sequences, MSSQL erfordert die Umschreibung sämtlicher Tabellen-Joins (und möglicherweise weitere Anpassungen). Doppelter Code ist schwerer zu warten, Sequences erfordern eine deutliche Ausweitung der Datenbank-Abstraktionsschicht und das Umschreiben aller Joins kommt schlicht nicht infrage.

Dateiverwaltung:

Tags werden nun versioniert, alle dadurch entstehenden Probleme und Unannehmlichkeiten konnten gelöst werden. Die Methoden zur Verwaltung von angehängten Dateien im Dateisystem oder der Datenbank sind jetzt fertig. Die Datenbankkonfiguration wird aus einer Datei eingelesen. Der komprimierte Quelltext ist jetzt 146 KiB groß. Leider geht die Entwicklung derzeit sehr langsam voran, da ich nicht viel Zeit dafür übrig habe. Aber das wird sich auch wieder ändern.

Versionierte Tags?

Vor kurzem bin ich zur möglichen Vereinfachung des Konzepts auf eine wegweisende Frage gestoßen: Sollen die Tag-Zuordnungen von Beiträgen gemeinsam mit dem Inhalt versioniert werden? Das könnte die Dateiverwaltung deutlich vereinfachen, aber auch zu mehr Aufwand bei einer Suchanfrage führen. Alle Hintergründe und Details sind im Boardunity-Forum nachzulesen. Leider bislang ohne Reaktionen... Ich würde mich über etwas Feedback und neue Gedanken freuen.

Basis-Klassen implementiert

In den letzten Wochen habe ich angefangen, die Basis-Klassen zu implementieren, die den Umgang mit Mitteilungen, Revisionen, Tags und Benutzern ermöglichen und dafür auf die Datenbank zugreifen. Datenprüfung, Zugriffsschutz und Moderationsfunktionen sind bereits enthalten. Derzeit entsteht die Verwaltung hochgeladener Bilder und Dateien, anschließend kommt die Suchfunktion dran. Dies ist nur ein Status-Update, heute gibt’s nichts weiter anzuschauen. Diese Basis-Klassen enthalten keine „schöne“ Benutzeroberfläche, zum Testen verwende ich eine einfache Formularsammlung, die noch nicht annähernd an das geplante Zielsystem erinnert. Ein paar technische Daten der bisherigen Arbeit:

Erforderliche PHP-Version:	5.1.2 mit PDO und Multibyte Strings
Verwendete PHP-Features:	Klassen (keine globalen Funktionen), Methodensichtbarkeiten (z. B. Singletons und statische Klassen), Exceptions, Konstanten
Erforderliche Datenbank:	MySQL 5.0.15 mit InnoDB, SQLite 3.2.3 (PostgreSQL 8.2 mit Einschränkungen, Oracle noch nicht getestet, SQL Server 2005 wird nicht unterstützt)
Verwendete Datenbank-Features:	Prepared Statements, Transaktionen, referentielle Integrität (in SQLite durch Trigger umgesetzt), Subqueries, persistente Verbindungen
Effektive Codezeilen:	knapp 3 500
Minimale Codegröße:	130 KiB (ausführbar komprimiert auf ca. 55%)

Zugangssteuerung und Moderation ausgetüftelt

Ich habe nun meine Gedanken zu den Themen Zugangssteuerung und Moderation geordnet und präzisiert und eine geeignete Datenstruktur entworfen. Herausgekommen ist eine schon recht konkrete Beschreibung des geplanten Systems.

Markup-Übersetzer implementiert

Mit leichten Änderungen der zuvor spezifizierten Syntax habe ich nun eine erste Version des Markup-Übersetzers fertiggestellt, der den Klartext der Beiträge wie vom Benutzer eingegeben in HTML übersetzt, um ihn formatiert im Browser anzuzeigen. Die größte Abweichung in der Syntax ist, dass nicht mehr // und ** für Kursiv- und Fettdruck der Schrift verwendet werden, sondern ähnlich der Wikipedia-Schreibweise zwei, drei oder mehr Apostrophe zur Hervorherbung von Text dienen. Der Text erscheint dann ''kursiv'', '''fett''' oder ''''kursiv und fett''''.

Im Demo-Formular kann man das gute Stück gleich ausprobieren.

Formulierte Ideen zur Benutzerschnittstelle

• Vergleich der Konzepte
• Was ist ein Beitrag?
• Darstellung der Inhalte
• Textformatierung (Markup)
• Zugangssteuerung (Access Control)