[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Opening the debate re moving to 2.6 again
From: |
Horst Herb |
Subject: |
Re: [Gnumed-devel] Opening the debate re moving to 2.6 again |
Date: |
Thu, 8 Sep 2005 22:21:14 +0000 |
User-agent: |
KMail/1.7.2 |
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
- Re: [Gnumed-devel] secure messaging, (continued)
- Re: [Gnumed-devel] secure messaging, Karsten Hilbert, 2005/09/12
- Re: [Gnumed-devel] secure messaging, J Busser, 2005/09/17
- Re: [Gnumed-devel] secure messaging, Tony Lembke, 2005/09/08
- Re: [Gnumed-devel] secure messaging, Karsten Hilbert, 2005/09/09
- [Gnumed-devel] Re: Opening the debate re moving to 2.6 again, Andreas Tille, 2005/09/05
- Re: [Gnumed-devel] Opening the debate re moving to 2.6 again, Karsten Hilbert, 2005/09/05
- Re: [Gnumed-devel] Opening the debate re moving to 2.6 again, Richard Terry, 2005/09/05
- [Gnumed-devel] Re: Opening the debate re moving to 2.6 again, Andreas Tille, 2005/09/06
- Re: [Gnumed-devel] Re: Opening the debate re moving to 2.6 again, Sebastian Hilbert, 2005/09/06
Re: [Gnumed-devel] Opening the debate re moving to 2.6 again, Syan Tan, 2005/09/08
- Re: [Gnumed-devel] Opening the debate re moving to 2.6 again,
Horst Herb <=