Generischer Layereditor: Unterschied zwischen den Versionen
| 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. | 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: | 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 Suchfunktion mit Ergebnisdarstellung | |
| − | + | # Ein Dateneingabeformular | |
| − | + | # Ein Datenänderungsformular | |
| − | + | # 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. | 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. | 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. | ||
Version vom 21. Juni 2006, 16:32 Uhr
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:
- Die Layeranzeige
- Die Suchfunktion mit Ergebnisdarstellung
- Ein Dateneingabeformular
- Ein Datenänderungsformular
- 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?
