Martin Brenda schrieb:
>> Gibt es denn gute PHP-Template-Engines, damit man hier auch Design von
>> der Funktion trennen kann?
>>
> Ich verwende Smarty (smarty.php.net) und bin sehr zufrieden mit dieser
> Template-Engine.
>
Smarty ist nicht schlecht, das stimmt, auch, wenn ich mir in letzter
Zeit meist selbst meine Template-Systeme geschrieben habe bei eigenen
Projekten - die sind dann aber meist wesentlich einfacher gestrickt.
> Bevor wir aber weiter ins Detail gehen, sollten wir die Organisation mit
> Thomas abklären. Vor allem was die in den letzten Tagen hochgekommene
> Aufteilung in Teilprojekte bzw. Abspaltung des komplexeren (mit Gültigkeiten)
> Projekts vom Ortsprojekt angeht.
>
Ich denke, ein Stück weit können wir hierbei nebenläufig arbeiten.
Auf jeden Fall - unabhängig davon, wie weit das Projekt gespalten oder
aufgeteilt wird - müssen wir die Oberfläche so modular halten wie
möglich, damit weitere Attribute oder Entities relativ aufwandsarm
angehängt und in die Oberfläche eingebaut werden können.
Ich stelle mir das etwa so vor:
I. Abfragen aus der Datenbank
Klassische Abfragen, die häufig genutzt werden, sind, denke ich, die
Lage und die Entfernungssuche, wie sie auf den bisherigen
opengeodb-Seiten als Beispiele verfügbar sind, sowie die Umkreissuche.
Dies setzt voraus (ohne mich damit jetzt direkt auf die DB-Struktur zu
beziehen):
* Welche Orte (Name (erstmal min. 1) liegen wo (Koordinaten)
Strukturabfragen, die als Beispiel irgendwie auch schon mit da drinstecken:
* Wie ist der Ort in die Verwaltungshierarchie eingegliedert? =>
benötigt die Verwaltungshierarchien
Kartenanfragen
* 1-2 Orte sind bereits realisiert auf der Website, müsste entsprechend
übertragen werden.
Damit komme ich auf benötigte Daten:
- Hierarchien,
- Koordinaten (erstmal Punkte)
- Namen
Weitergehend wären da Grenzlinien, die bisher in der opengeodb noch gar
nicht erfasst sind sowie weitere Daten zu den Orten, aber mit den oben
genannten könnte man anfangen, ohne dass es irgendwo problematisch wäre.
Sicherzustellen bei diesen Daten ist natürlich die Verfolgung des
Änderungsverlaufs sowie eine Art Freischaltungsprozess. Bei der Eingabe
von Daten durch "Fremde" wäre zusätzlich vielleicht ein Feld für die
Quellenangabe ganz nützlich, damit wir wenigstens in einigen Fällen
Daten einfach ablehnen können, die rechtlich problematisch sind.
> Als ich mich gestern nocheinmal durch die OpenGeoDB-Seite geklickt habe, ist
> mir aufgefallen, dass es ja noch GeoClassPHP gibt. Dies kann man ja
> eigentlich auch als eine Art "Teilprojekt" auffassen.
>
Soweit ich weiß, wird die geoclassPHP aktuell kaum gepflegt. Sicher -
ich würde den gesamten Ansatz der Oberfläche objektorientiert angehen,
und insofern gehört auch die geoclass oder etwas entsprechen ähnliches
mit dazu. Wie das genau da reinpasst, bleibt aber abzuwarten und zu
untersuchen, denke ich.
mfg
Peter Wendorff
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb-r1mDYR0DdAyzQB+pC5nmwQ@xxxxxxxxxxxxxxxx
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
|
