Re: [Gnumed-devel] Opening the debate re moving to 2.6 again

[Horst Herb]

On Thu, 8 Sep 2005 14:18, Syan Tan wrote:
>  seems pretty quiet  for what seems to be the most

Syan, 

don't waste your time on my code yet.

The history behind it:
- I was dissatisfied with the medibase user interface, needed something 
platform independent quickly. So I wrote a web interface (which is still in 
use at our hospital) 
But a web interface doesn't allow proper *speedy* user interaction, so I 
resorted to wxPython. I ended up with a very functional but rather ugly quick 
hack, a patchwork without any real underlying architecture. I am still sing 
it in daily practice but I am rather ashamed for it's ugly code.

So I started to rewrite the system, this time I wanted to do it properly, and 
using a non-proprietary backend schema. But then I felt the time pressure, 
everybody wanted to see it, and in order to produce something demonstrable 
for a presentation at a conference here, the lot degraded again into a hacky 
patchwork 

I want to clean that up and document it properly before I bother people with 
it. Your time is as valuable as my time, and you shouldn't waste it mopping 
up my own sloppiness.

In principle, the architecture looks like that:

a) every database concept (like "a patient", "a doctor", "an address" etc.) is 
wrapped into a gmdbXXX class with standardized high level accessor methods. 
They all inherit common traits from a gmdbObject ancestor including a very 
simple and crude caching mechanism.  There should be no SQL queries at all in 
the GUI code

b) every possibly self-contained functionality (e.g. "prescribing", 
"appointment booking") exists as an independent module which can be run 
either standalone or as a plugin within the gnumed framework

c) all such independent modules ( regardless whether gui or not) communicate 
with each other exclusively via the central messaging hub (dispatcher)

d) as a rule, GUI components are designed with wxGlade. The generated GUI code 
is never modified manually, but a wxXXX module inherits from the generated 
wxglXXX module. That allows non-programmers to modify the GUI as long as they 
don't change any object names.

e.) The GUI framework is a naked window subdivided by resizeable ("sash") 
subwindows. To start with, the screen is subdivided top and bottom, and left 
and right. In the center there is an empty notebook widget with just a 
patient search widget in it. Everything else is added by the user via plugin, 
and the user determines where on the screen the plugin will appear. All 
subwindows are user resizeable, and the framework remembers the sash 
positions between sessions.

f) Not only for simplicity, but also for speed reason, the backend schema is 
not always normalized. At times, where it would yield a substantial 
performance gain, foreign keys *may* be the data itself as long as the data 
will alway be unique, saving an extra query join (mostly used for 
enumerators, e.g. "title", "cardtype").

g) the backend schema is versioned. Modules check what backend version they 
need. The backend is updatable incrementally - after the first full version 
number, only "update" schema sql snippets will be generated, allowing update 
of a running system without anybody having to log out first

h) installation should be running "gnumed.sh" and "python setup.py install" 
and nothing else, no hoops to jump through for the end user. This requires an 
administrator running gnumed.sh as somebody who has the right of creating new 
postgres databases and users

Horst