Re: [Gnumed-devel] vb2py - might help Richard - PS

[Horst Herb]

On Wed, 18 Aug 2004 09:27, Richard Terry wrote:
> BTW how is your mini-gnumed going.

Poorly. I just lodged my hospital claims - did 400 (four hundred) hours on 
call last month on call alone, that's a hundred hours per week. Plus at least 
12 hours every day working in my surgery, since one of my assistants has 
quit.

On top of that, medibase had a lawsuit from medical director, they were forced 
to change their whole table structure radically which required me to rewrite 
my own gnumed-mini <-> medibase translators with highest priority so that I 
can continue my clinical work. Haven't even fully finished the latter yet.

> And also could you reply to my question as to the whole flow of the gnumed
> database accessing > translating data into the text wigits in
> gmDemographics cause that is where I'm stuck at the moment.

I do not know how mainstream gnumed is doing it currently. Might be similar to 
what I do in gnumed-mini:

1.) all panels containing widgets register their interest with the dispatcher 
in events that might affect the data they display
2.) if such event is notified, the panel updates it's widgets or the backend 
from data within the widgets or both
3.) The panel's event handler either queries the database service directly, or 
via (cached) business objects: here is where gnumed-mini might differ, since 
I now use a protocol where whichever object queries the database and 
retrieves results, broadcasts these results via dispatcher (wrapped in a 
dictionary object)

Example:
1.) your panel registers a "PatientChanged" event interest
2.) The patient selector selects a patient, and 
 a) retrieves basic demographic information from the backend
 b) emits a "PatientChanged" event with the query result as parameter

This is very simple, yet efficient:
- such parameters are passed "by reference" (just a pointer), hence no memory 
wasted
- no complex business objects required
- cache doesn't become stale
Problem with this approach:
- programmer has to show discipline in not modifying the passed around 
dictionary object containing the results without making a local copy first

So, if you have a widget containing the patients surname, you would have your
"OnPatientChanged(record) function registered with the dispatcher as callback 
for the "PatientChanged" event.

The OnPatientChanged(record) function might then contain a line like:
mySurnameTextWidget.SetValue(record['patient.surname'])

Is that helpful or do you need information at a more specific level?

Horst