Bolsena 2009 Ideas
From MapbenderWiki
Hier Vorschläge, was programmiert werden soll.
Contents |
Kernfunktionalität / Benutzerspezifische Inhalte (User:Christoph Baudson)
Abstract
Mapbender ist nicht in der Lage festzustellen, ob ein Element einer Applikation valide ist. Eine Unterscheidung zwischen Kernfunktionalität (Applikationselementen, die gepflegt und getestet sind) und benutzerspezifischen Inhalten (vom Benutzer selbst angelegte oder veränderte Elemente) würde es erleichtern, Fehlkonfigurationen zu vermeiden und den Wartungsaufwand zu senken.
Vorgehensweise
- Identifizierung der Kernfunktionalität. Welche Module werden ausgeliefert und gepflegt? Siehe Postings auf Mapbender-dev, 1, 2. Man sollte die Abhängigkeiten zwischen den Modulen prüfen (Erstellung eines Abhängigkeits-Graphen)
- Trennung der Tabelle gui_element in element und gui_element. Die Tabelle element enthält die Attribute, die ein Element eindeutig identifizieren (diese dürfen bei Kernfunktionalitäten nicht verändert werden!), die Tabelle gui_element enthält die Konfiguration eines Elements für eine Applikation. Man könnte es auch aristotelisch als substanzielle und akzidentielle Kategorien begreifen. Siehe auch Posting auf Mapbender-dev und ff.
- Nutzung des jQuery Plugin-Systems, siehe Blog. Dies hätte auch den Vorteil, dass man die Module einfach dokumentieren könnte; die Wiki-Dokumentation würde entfallen.
- Anpassung der Administrationsoberflächen. Mit dem Abhängigkeitsgraphen könnte die Validität prüfen. Man könnte das im GSoC 2008 entwickelte HTML-Gerüst verwenden. Erweiterung der "Elemente arrangieren"-Oberfläche von Bolsena 2008: Man könnte ein Repository haben, aus dem man sich bedienen kann, wenn man eine Applikation mit Elementen bestückt (Also Applikationen neu entwerfen, nicht nur bestehende verändern).
RESTful API
Abstract
Um auf Dienste, Applikationen und Benutzer in Mapbender zuzugreifen, gibt es keine wohldefinierte Schnittstelle. Eine RESTful API könnte diesen Zweck erfüllen. Mapbender würde dadurch modularer werden, und würde die Kollaboration mit anderer Software erleichtern: Man könnte sich zum Beispiel eine Trennung von Mapbender-Client und -Server vorstellen, wobei die Serverkomponente auch von anderen Clients angesteuert werden könnte.
Update/Installation/Build
Abstract
Während des Google Summer Of Code ist ein Update-Konzept erarbeitet worden, dessen Umsetzung aber noch einigen Feinschliff benötigt. Das Update der Dateien (durch Verwendung von Prüfsummen) ist weniger kompliziert als das Datenbank-Update. Es wäre erstrebenswert, sich auf ein Format zu einigen, in dem die SQLs vorliegen. Zudem wäre es hilfreich zu wissen, welche Module upgedatet werden (siehe Thema "Kernfunktionalität"), und wie man mit benutzerspezifischen Modulen umgeht.
Ein Installationsskript könnte in PHP implementiert werden. Ein Shellskript für die Datenbankinstallation existiert bereits.
Build-Vorgang: Das Datenbankschema kann aus einem Dia-ER-Diagramm in ein SQL exportiert werden (MySQL und PostgreSQL). Für den Build-Vorgang wäre evtl. auch die API interessant, da man darüber Benutzer, Applikationen und Dienste über ein Skript gesteuert anlegen könnte. Man könnte dann auch nicht aktive Dienste aus dem Dump rausfiltern.
Sicherheit / Encoding
Abstract
Man könnte die Schnittstellen von Mapbender dahingehend prüfen, dass keine Sicherheitslücken vorhanden sind und alle Ein- und Ausgabeströme korrekt kodiert sind.
Quality Check / Improvement
Abstract
- check Mapbender branch/2.6 for release Mapbender 2.6
- Digitize / simplify the workflow
- Gazetteer
- WFS 1.1.0
- fix the reported bugs
- GUI Categories
- check arrange elements
- debug print_dynamic, PrintPDF with template
Documentation
- publish Mapbender 2.6 documentation (de) Astrid
- improvements for tutorial
Visibility Workgroup
- improve Mapbender visibility
WPS
Integration in Mapbender
Style Improvements
- often people say Mapbender looks old fashion. Let's discuss what we can do to make Mapbender sexy
Pakete bauen
http://www.heise.de/open/Ubuntu-Paketbau-leicht-gemacht--/news/meldung/139609
