Schemata und Web-Applikationen

Wegen aktueller Erfahrungen bei einem Kunden möchte ich ein Thema ansprechen, das man nicht oft genug betonen kann :

Wenn man eigene Web-Services wie z.B. Formulardienste oder Pflegeapplikationen mit PHP und dabei auch noch objektorientiert entwickelt, dann lohnt es sich unbedingt, hierbei so vorzugehen, dass die

  • grundlegenden Datenbank-Strukturen (Tabellen, Felddefinitionen, Master-Detail-Relationen),
  • essentielle Elemente der Datenprüfung/-Validierung,
  • Objekte für die Repräsentation von Webformularen,
  • Objekte der Datenbankinteraktions-Schicht und
  • die darüber liegenden Pflegeapplikationen

auf der Basis von sog. zentralen “Datenschemata” quasi generiert werden. Dabei kann man sogar Vorgaben für die Repräsentation von Master-Detail-Relationen integrieren.

Natürlich ist der Aufbau entsprechender eigener Frameworks mühsam – aber es lohnt sich nach unserer Erfahrung schon ab dem zweiten Projekt.

Die zentrale Idee ist die, dass man sich ein “Framework” so aufbaut, dass durch die programmtechnische Auswertung von vorgegebenen “Datenfeld-” und “Validierungs-” Beschreibungen (“Schema”)

  • sowohl die benötigten Datenbank-Tabellen generiert
  • als auch zugehörige Pflegeapplikationen in einem “Rutsch” (durch reines Kopieren von Dateien) bereitgestellt werden können.

Die entsprechenden Objekte müssen so “intelligent” sein, dass sie aus der vorgegebenen Datenstruktur-Information des “Schemas” die richtigen Schlüsse ziehen : D.h., dass sie die benötigten SQL-Statements und Validierungsstatements innerhalb der Pflege- und Applikationslogik und die zugehörigen Web-Formulare dynamisch aufbauen, wobei Sie immer gleiche Klassendefinitionen heranziehen.

Salopp ausgedrückt folgt man dabei der Devise: “Gib mir deine Datenstruktur und ich gebe dir eine erste komplette Pflegeapplikation auf der Basis eines universellen Model-View-Controllers und einer universellen Datenbank-Interaktionsschicht an die Hand.” PHP ist für den Aufbau solcher Frameworks aus unserer Sicht seit PHP5.2 geradezu ideal geeignet.

Baut man die Pflegefunktionalität selbst modular in Funktionalklassen auf, so verschafft man sich gleichzeitig die Basis für komplexere und spezialiserte Business-Applikationen, denen man dann Schema-Objekte übergibt. Aus der Schema-Information werden dann nach Bedarf automatisch Objekte für die Repräsentation einzelner Datensätze oder ganzer Listen von Datensätzen generiert. Die Interaktion mit der Datenbank tritt dann für die Business-Logik in der Regel fast völlig in den Hintergrund.

Bei Erweiterungen um Felder ändert man primär das entsprechende “Schema” und schon läuft die erweiterte Applikation – vorbehaltlich inhaltlicher Erweiterungen der Business-Logik. Es liegt auf der Hand, dass sich die anfängliche Mühe bei der Erstellung “schemabasierter” Frameworks schnell lohnt.

Opensuse 11, sensors und IT8720

Wer sich – wie ich – ein neueres Board beschafft hat, wird u.U. feststellen, dass die HW-Sensoren ein Kernelmodul zur Unterstützung der  ITE 8720 Super IO Sensors benötigen. Opensuse 11.1 liefert für den 2.6.27-Kernel allerdings nur ein älteres IT87-Modul, das für die neueren Chipsätze nicht ausreichend ist.

Netterweise gibt es ein paar Kollegen, die sich die Mühe gemacht haben, die für den Kernel 2.6.29 bereits erstellten Module auf den älteren Kernel zurückzuportieren und entsprechende RPM-Pakete für den aktuellen Stand des SuSE-Kernels bereitzustellen.
Hier wird man im Internet fündig :

http://forums.opensuse.org/hardware/410081-sensors-ite-it8720-not-working.html

http://download.opensuse.org/repositories/home:/Akoellh/

Das erweiterte IT87-Kernelmodul funktioniert prächtig und kann nach “sensors-detect” in der Datei “/etc/sysconfig/lm_sensors” eingetragen werden – in meinem Fall lauten die Einträge:

MODULE_0=”coretemp”
MODULE_1=”it87″

Natürlich kann man unter Yast2 auch den sysconfig-Editor verwenden. Das entsprechende Startup-Skript “lm_sensors”, das diese Einträge nutzt, findet man natürlich unter “/ect/init.d”.

Vielen Dank an Akoellh !