[opengeodb] OpenGeoDB Webinterface

[Andreas Hubel]

Hi,

ich hab mich grade durch die ganzen Beiträge der letzen Wochen 
durchgeschlagen und will mal versuchen ne Zusammenfassung des ganzen zu 
machen:

Um die Sache mit den Gültigkeiten (von-bis) zu vereinfachen, wird das 
Projekt OpenGeoDB in zwei Teilprojekte gegliedert.
Teilprojekt 1 bleibt so ungefähr wie es momentan ist, also mit 
historischen Daten.
Teilprojekt 2 lässt die historischen Daten zwecks Vereinfachung links 
liegen.

Alles weitere bezieht sich nun nur noch auf Teilprojekt 2, auch wenn ich 
vergessen sollte das zu erwähnen.

Für Teilprojekt 2 wird ein Webinterface mit Wiki-ähnlichen Funktionen 
erstellt. Das heißt möglichst einfaches Bearbeiten durch jeden, Historie 
mit allen Änderungen, Übersicht über die letzen Änderungen, Löschen nur 
durch Admins und selbst für die kein entgültiges Löschen.
Im Prinzip könnte man sich da gut an Wikipedia / Mediawiki orientieren...

So, ich hoffe das passt soweit alles. Jetzt kommt zwar weiterhin ein 
bischen Zusammenfassung, allerdings auch mehr Vorschläge von mir.

Programmiersprache dieses Projektes wird wohl PHP sein, obwohl andere 
nicht schlecher wären, allerdings können wohl die meisten hier PHP am 
besten. (kA warum ;-))

Zuerst sollte man sich über die Rahmenbedingungen einigen, z.B. ob und 
welches Framework und Templatesystem man verwedet.

Parallel dazu sollte jemand mit den entsprechenden Rechten auf dem 
OpenGeoDB Server nen SVN Server einrichten. Am besten so, dass das Zeug 
beim einchecken ins SVN automatisch auf nem Webserver landet, so dass 
immer der aktuelle Stand der Anwendung auch im Web nutzerbar ist. (Ich 
hab sowas schonmal mit gemacht, ist also möglich). Für das SVN sollte 
man am besten auch gleich noch nen Onlineviewer installieren. Wenn das 
steht sollte jeder, der mitarbeiten möchte relativ einfach 
Schreibzugriff darauf bekommen, d. h. nicht so geizig mit den Accunts 
umgehen. Evtl. wäre auch noch nen Aufgabenmanger nicht schlecht.

Damit haben wir dann ne Basis auf der man aufsetzen kann.

Ich würde dort dann zuerst mal das ganze Anzeige-Zeug, das momentan so 
verfügbar, dazu nutzen einen guten Webviewer für die OpenGeoDB mit 
ansprechendem Style und striktem XHTML und CSS bauen. Nach und nach kann 
man darin dann die Bearbeitungsfunktionen einbauen. Man muss das Ding 
einfach Schritt für Schritt wachsen lassen.

Dabei sollten wir auch gleich darauf achten in Schichten zu 
programmieren, und das ganze alles zu trennen. Das soll heißen, das im 
eigendlichen Fontent sogut wie keine SQL-Queries stehen sollten, die was 
an der Datenbank maniplulieren. Ich stelle mir da einzelne Funktionen 
vor, die die entsprechenden Parameter übermittelt bekommen. Am besten 
wäre natürlich das so Objektorientiert wie möglich zu machen. Dadurch 
hätte man auch ne schöne Schnittstelle um Masseneintragungen zu tätigen.

Zur Tabellenstruktur:
Ich würde die Tabellenstruktur so lassen wie sie ist (absehen von den 
oben ansgesprochenen Gültigkeitszeiträumen) und weitere Tabellen 
hinzufügen, in der dann die alten Einträge gehalten werden. Dabei sollte 
jede Änderung zuerst in der Historie Tabelle landen und dann in die 
offizielle Tabelle übernommen wird. (Damit liese sich auch ne evtl. 
Prüfungsfunktion einfacher umsetzen, aber die sollte erst eingesetzt 
werden, wenn es uns mal wie der Wikipedia geht.) Das heißt die Daten die 
aktuellen Daten wären immer doppelt in der DB, aber diese Lösung ist 
immer noch besser als die Änderungen erst bei der nächsten Änderung in 
die Historietabelle zu verschieben (da sprech ich aus Erfahrung)
In dem Bereich könnten wir uns stark an den Verfahren von SVN anlehnen. 
Das ganze mal kongret in Tabellen ausgedrückt. Eine Tabelle Revisions 
(rev_id, user_id, comment, date) und jeweils ne Kopie der bisherigen 
Daten Tabellen, nur mit ner zusätzlichen rev_id. (wobei man sich dann 
überlegen sollte, ob man dort nicht noch ne zusätzliche Primär ID 
einführt, aber das kann man ja später, während der Entwicklung immer 
noch machen).

Die Änderungen werden dann immer Revisionsbezogen gespeichert, deshalb 
würde ich die Änderungsfunktionen irgendwie in ne Revisionsklasse 
stecken, ums einfacher auszurücken hier etwas Pseudocode:
$rev = new revision($user, $date);
$rev->edit_coords($loc_id, $lat, $lon [...]);
$rev->edit_text($loc_id, $type, $val [...]);
$rev->add_text($loc_id, $type, $val [...]);
$rev->edit_int($loc_id, $type, $val [...]);
$rev->edit_float($loc_id, $type, $val [...]);
$rev->delete_int($loc_id, $type);
$rev->submit();

So ich hoffe, dadurch hab ich den Vorschlag mit den einzelnen Schichten 
evtl. noch etwas verdeutlicht.

Ich hoffe ich hab das verständlich genug geschrieben und in der alles 
Zusammenfassung korrekt wiedergegeben. Ich wollte einfach meine 
Meinungen und Ideen zu dem Thema weitergeben.

MfG Andreas Hubel