GNUmed - Webinterface , wie angehen ?

release_dude · Dienstag 9. März 2010, 20:07

Hallo,

Ich arbeite mit an GNUmed (Arztpraxissoftware, GPL, wxpython, PostgreSQL, psycopg2).

Nun habe ich überlegt wie man es anstellen kann für GNUmed ein Webinterface zu bauen.

Ich selbst bin Python-Anfänger und habe mit Web-Frameworks keine Erfahrung. Mir geht es mehr um theoretische Überlegungen.

Es gibt ja unzählige Web-Frameworks. Ganze Flamewars werden da ausgetragen.

GNUmed nutzt psycopg2 für den Zugriff auf PostgreSQL. Dazu haben wir eine sogenannte middleware, die die Oberfläche wxpython weitgehend unabhängig von der Datenbankstruktur machen soll. Prinzipiell wäre auch eine PyQT-Oberfläche möglich.

Nun überlege ich ob und wie es möglich ist die vorhandene middleware weiter zu nutzen. Ich will also python-code (z.B. gmPG2 - GNUmedmodul für Datenbankzugriff) aus dem Browser ansprechen.

Irgendjemand hat mal gesagt das müsse man über XML-RPC machen.

Wer kann hierzu was beitragen ?

Vielen Dank,
Sebastian Hilbert
GNUmed-Team

BlackJack · Dienstag 9. März 2010, 20:30

@release_dude: Das *muss* man nicht über XML-RPC machen. Von JavaScript in einem Browser aus, würde sich JSON-RPC mindestens genausogut machen.

Die Frage ist, ob der bisherige Code ordentlich von der GUI getrennt ist. Falls ja, ist es wahrscheinlich nicht sooo schwer eine Weboberfläche dafür zu programmieren. Kommt natürlich auch immer ein bisschen darauf an, ob sich die verwendeten GUI-Komponenten gut auf Webseiten abbilden lassen.

release_dude · Mittwoch 10. März 2010, 07:39

Hallo,

Die GUI ist gut getrennt. Falls nicht genug dann wird an dieser Stelle nachgearbeitet.

Die Widgets lassen sich größtenteils übertragen.

Jetzt noch eine Anfängerfrage. Brauche ich überhaupt ein Webframework wenn ich einen teil davon nicht nutze (Datenbankanbindung). Wenn ich das richtig sehe dann würde die Anmeldung an der DB auch nicht übers Framework sondern selbst geschrieben über XML/JSON-RPC laufen.

Braucht man da noch das Webframework (Django, Turbogears) ?

Hat irgeng ggf einen Link wo sowas schon mal gemacht wurde (vorhandener Code ist immer gut um zu lernen)

Sebastian

jens · Mittwoch 10. März 2010, 08:30

Django bietet ein Object-relational mapper (kurz ORM), damit man es einfacher hat, auf die Datenbank zu zugreifen. Wäre dumm, das ORM nicht zu nutzten.

Ich würde vielleicht einfach mal so anfangen:
Django's inspect DB nutzten, um automatisch Datenbank Modelle generieren zu lassen: http://docs.djangoproject.com/en/dev/re ... -inspectdb
Die automatischen Modelle ein wenig anpassen.
Für jedes Model eine ModelAdmin Klasse erstellen, damit man es im Django Admin Bereich sieht/bearbeiten kann: http://docs.djangoproject.com/en/dev/re ... in-objects

Wie der Admin Bereich aussieht, kann man ein wenig hier sehen: http://docs.djangoproject.com/en/dev/intro/tutorial02/

Danach hat man schon mal einen rudimentären Web Zugriff auf die GNUmed Datenbank. Die kann man dann schritt für schritt anpassen. Weiterhin kann man dann eigenen views schreiben, wenn man kompliziertere Sachen machen möchte...

Ich würde vorschlagen, erst mal das Django Tutorial durch zu arbeiten, damit erwirbt man sich alle Grundkenntnisse:
http://docs.djangoproject.com/en/dev/intro/tutorial01/

release_dude · Mittwoch 10. März 2010, 09:30

Hallo,

Vielen Dank für die ausführliche Antwort. Werde ich mir gleich anschauen.

Eine Frage bleibt aber. Macht es Sinn mit Django direkt auf die Datenbank zuzugreifen und ggf. eigene views zu schreiben ?

Hintergrund der Frage: Wenn sich das Datenbankschema ändert fange ich an in Django den Code zu ändern.

Die GNUmed-Middleware hingegen ist relativ stabil. Wenn sich das Datenbankschema ändert dann wird gmPG2 angepasst (middleware Objekt). Ich greife von der GTK GUI oder Webinterface auf gmPG2 zu und muss mich also nicht darum kümmern wenn sich was am Datenbankschema tut.

Daher versuche ich sauber herauszuarbeiten ob es Sinn macht bei einem Webinterface kommplett gmPG2 zu umgehen und direkt mit der Datenbank zu kommunizieren ?

Als Anfänger stelle ich mir so etwas wie einen Proxy vor. Der Proxy empfängt Anweisungen/Funktionsaufrufe aus dem Webinterface und leitet diese an die existierende middleware weiter.

Was GNUmed schon hat ist eine XML-RPC-Schnittstelle. Damit kann ich mit drei Zeilen Python GNUmed fernsteuern. Also z.B. gezielt Patienten aufrufen in einem laufen GNUmed.

Es gibt da in der middleware z.B. die Datei gmPerson und darin die Klasse cPatientSearcher_SQL. Das würde ich natürlich gerne ansprechen um nach Patienten zu suchen anstatt den getesteten Code wegzuwerfen und direkt auf die Datenbank zuzugreifen.

Vielleicht geht das ja gar nicht was ich mir vorstelle.

Danke für die Hinweise,
Sebastian Hilbert

BlackJack · Mittwoch 10. März 2010, 11:08

@release_dude: Wenn die Datenbankzugriffe schon komplett gekapselt sind, würde ich nicht an dieser Schicht vorbei auf die DB zugreifen. Wie Du schon sagtest, machst Du Dir damit ja doppelte Arbeit. Und wenn die Middleware etwas anders macht als Dein Zugriff übers Web, kann man sich auch Unstimmigkeiten in den Daten einhandeln.

Ob Django ohne ORM noch soviele Vorteile bietet kann ich nicht sagen.

Plan doch einfach mal ein bisschen Zeit ein, um einen oder mehrere kleine Prototypen zu programmieren.

release_dude · Mittwoch 10. März 2010, 12:24

Also wenn ich das richtig verstanden habe dann muss ich mich mit JSON-RPC und/oder XML/RPC beschäftigen ?

Vielen Dank,
Sebastian Hilbert
GNUmed team

Leonidas · Mittwoch 10. März 2010, 12:32

Was spricht eigentlich dagegen, die Middleware, die ja auch in Python geschrieben zu sein scheint, einfach direkt im Backend zu importieren und sich den ganzen RPC-Kram zu sparen?

release_dude · Mittwoch 10. März 2010, 13:10

@Leonidas.

Was dagegen sprich ? Meine Unwissenheit

Deswegen habe ich hier nachgefragt was ihr so dazu sagt. Wenn jemand zu mir sagt. Das mit dem XML-RPC ist grober Unfug und man soll das so oder so machen dann bin ich sehr dankbar.

Könntest du ggf. etwas genauer erläutern was du mit direkt ins Backend importieren meinst ? Backend wovon ?

Ich brauche in erster Linie Hinweise in welche Themen ich mich einlesen muss.

Vielen Dank für eure Hilfe,
Sebastian Hilbert
GNUmed team

Leonidas · Mittwoch 10. März 2010, 13:14

Also naja, ich würde, wie BlackJack meint, die Middleware zur Verarbeitung der Daten nutzen. An dieser Stelle macht Django nicht mehr so wahnsinnig viel Sinn, wenn man das ORM nicht nutzt dann ist Django nicht mehr so der Hit.

Daher würde ich einfach ein Framework wie Pylons oder Glasshammer oder auch einfach nur so Libs wie Werkzeug oder Bottle nehmen und einfach mal anfangen.

jens · Mittwoch 10. März 2010, 13:24

Naja, Django besteht ja nicht nur aus ORM + Admin. Es bietet ja noch eine reihe weitere wichtigen Dingen:
* Template system
* URL routing
* Form Erzeugung/Validierung
* Cachen System
* Internationalisierung/Lokalisierung
* Session Verwaltung

und noch einiges mehr.

Dazu kommt: Wenn man sich einmal in Django eingearbeitet hat, kann man das Wissen halt auch nutzten um andere Web Applikationen zu erstellen...

Leonidas · Mittwoch 10. März 2010, 14:15

jens hat geschrieben:* Template system

Das hat man ohne Django mit Jinja auch. Ich habe das in meiner Webapp ersetzt und es hat sich auf jeden Fall gelehnt. Dabei ist Jinja kein Stück komplizierter oder langsamer als die Django-Templates. Eher im Gegenteil.

jens hat geschrieben:* URL routing

Die Regex-basierten Routen sind nicht so schön, finde ich. Flexibel, ja, schön eher weniger. Aber URL routing bringt ja jede Lib mit, selbst Werkzeug.

jens hat geschrieben:* Form Erzeugung/Validierung

Das ist tatsächlich nett, aber Spaß macht es am meisten wenn man die Forms aus dem Models generiert. Wenn man keine Models hat ist es genauso gut wie jede andere Form-Bibliothek.

jens hat geschrieben:* Cachen System

Das ist ein Vorteil, tatsache. Aber ob GNUmed das brauchen wird?

jens hat geschrieben:* Internationalisierung/Lokalisierung

Das finde ich in Django um ehrlich zu sein ziemlich grottig gelöst. Die Gettext-Übersetzungen lassen sich nicht im Admin ändern und für Multilingualen Content hat Django keinerlei Lösung. Natürlich, man kann sich auch was selbst basteln, aber das muss man in dem Fall so oder so.

jens hat geschrieben:* Session Verwaltung

Braucht die nicht auch das ORM?

Was Django für den OP bietet ist halt die große Community und die gelungene Dokumentation, die andere Frameworks (I'm looking at you, Pylons) so nicht haben.

jens · Mittwoch 10. März 2010, 14:19

Klar erhält man für jede Komponente auch entsprechenden Ersatz. Der Vorteil liegt aber in "alles aus einer Hand". Dokumentation, Support, Community, Bugtracker alles an der selben stelle.

Ich verweise mal auf: http://wiki.python-forum.de/Web-Frameworks (Obwohl man die mal wieder aktualisieren könnte)

release_dude · Samstag 13. März 2010, 14:29

Ich hätte es nie für möglich gehalten aber trotz meiner sehr rudimentären Python-Kenntnisse und nicht vorhandenen Cherrypy-Kenntnisse hat GNUmed ein funktionierendes Webinterface.

Danke an alle, die mich darauf gestossen haben, dass man Python-code direkt verarbeiten kann.

Einige Zeilen cherrypy aus den öffentlichen Beispielen gemischt mit einer herrlich getrennten middleware aus GNUmed haben es ermöglicht die middleware vom Webinterface zu 100% weiterzuverwenden.

Best regards,
Sebastian Hilbert