Generischer Layereditor - Versionsgeschichte

Markus Hentschel am 26. Juni 2006 um 08:07 Uhr

2006-06-26T08:07:22Z

Pkorduan am 21. Juni 2006 um 15:32 Uhr

2006-06-21T15:32:36Z

Pkorduan am 21. Juni 2006 um 15:31 Uhr

2006-06-21T15:31:02Z

Neue Seite

Was soll das sein.
Ein Layer ist ja über die Tabelle Layer schon ganz gut definiert.
Welche Daten im Layer ausgegeben und welche Attribute angezeigt werden sollen kann angegeben werden.
Die Anzeige der Daten erfolgt noch über ein Template, das könnte man schon generisch machen, also entspechend der Ergebnismenge der Abfrage. Die Sachdatentabelle wird einfach so breit wie die Anzahl der im Selekt-Statement definierten Attribute.
Wenn man zu den Attributen des Layers noch etwas genauer speichert was es für ein Datentyp ist, welche Werte darin vorkommen dürfen und wie das passende Formularelement aussehen soll (Text, Menü, etc.) könnte man auch auf ein Eigabetemplate verzichten.
Damit würde man einen Datenlayer nur an einer Stelle in der Datenbank definieren und hätte automatisch alles was man dazu braucht:
1) Die Layeranzeige
2) Die Suchfunktion mit Ergebnisdarstellung
3) Ein Dateneingabeformular
4) Ein Datenänderungsformular
5) Löschfunktion
Eigentlich genau das, was man von Desktop-GIS ja hinlänglich kennt. Komplizierter wird es nur wenn an Datenlayern andere Tabellen dran hängen in 1:n oder m:m Beziehung. Hier sind ggf. Abhängigkeiten und zu prüfen um Datenbankanomalien zu verhindern.
Bei der Beschreibung der Attribute sollte auch der Typ POINT, LINE und POLYGON etc. zugelassen sein. Je nach dem welcher Datentyp angegeben ist erscheint im Editor eben ein Kartenfenster mit Digitalisierfunktion oder ein Fenster zum Auswählen eines Datums.
Der Vorteil liegt auf der Hand:
Der Datenlayer und seine Attribute werden einmal sauber definiert und die Standardfachschale ist fertig.
An die Definition der Attribute ließen sich dann zusätzlich die Rechte hängen (sehen, ändern, löschen, Rechte ändern)

Na, was sagt's dazu?

← Nächstältere Version		Version vom 26. Juni 2006, 08:07 Uhr
Zeile 17:		Zeile 17:

	Na, was sagt's dazu?		Na, was sagt's dazu?
		+
		+	--[[Benutzer:Markus Hentschel\|Markus Hentschel]] 10:07, 26. Jun 2006 (CEST):
		+	Siehe Diskussion!

@@ Zeile 5: / Zeile 5: @@
 Wenn man zu den Attributen des Layers noch etwas genauer speichert was es für ein Datentyp ist, welche Werte darin vorkommen dürfen und wie das passende Formularelement aussehen soll (Text, Menü, etc.) könnte man auch auf ein Eigabetemplate verzichten.
 Damit würde man einen Datenlayer nur an einer Stelle in der Datenbank definieren und hätte automatisch alles was man dazu braucht:
-) Die Layeranzeige
+# Die Layeranzeige
-) Die Suchfunktion mit Ergebnisdarstellung
+# Die Suchfunktion mit Ergebnisdarstellung
-) Ein Dateneingabeformular
+# Ein Dateneingabeformular
-) Ein Datenänderungsformular
+# Ein Datenänderungsformular
-) Löschfunktion
+# Löschfunktion
 Eigentlich genau das, was man von Desktop-GIS ja hinlänglich kennt. Komplizierter wird es nur wenn an Datenlayern andere Tabellen dran hängen in 1:n oder m:m Beziehung. Hier sind ggf. Abhängigkeiten und zu prüfen um Datenbankanomalien zu verhindern.
 Bei der Beschreibung der Attribute sollte auch der Typ POINT, LINE und POLYGON etc. zugelassen sein. Je nach dem welcher Datentyp angegeben ist erscheint im Editor eben ein Kartenfenster mit Digitalisierfunktion oder ein Fenster zum Auswählen eines Datums.