Re: [Gnumed-devel] update on some test work.

[Ian Haywood]

On Tue, 04 Nov 2003 15:52:27 +1100
syan tan <address@hidden> wrote:

Looks good, I have one question:
why do PatientHolder classes need to have functions like get_allergies () to 
access diferent business objects?
Why can't the init-data and save-data functions just grab the business objects 
directly via gmCurrentPatient
like

gmCurrentPatient ().getEMR ().getPastHistory ()


You also create instances: gmCurrentPatient (kwds['id']) , this isn't 
necessary. gmCurrentPatient responds 
itself to patient_selected internally, any instance anywhere will already have 
this information.

I agree business object should try to produce a dictionary of data that can be 
passed to an edit area en bloc,
Perhaps we should have a business object ancestor that guarantees the methods 
getBasicData and setBasicData
In the demographics object getData would return for example 
{'firstname':'Ian', 'surnames':'Haywood', 'dob':'19/12/77', ....} the edit area 
could accept this dictionary and 
load widgets where the dictinary field matches the widgets name. 

However, it's not always that simple.
 For example, in the demographics object, we will have a list for the 
type of addresses (home, work, postal, etc.). When one of these is selected, a 
method must ask the business 
object for the "Home" address and load the widgets. Then, when another address 
type is selected, this data 
must be unloaded, and the new address data fetched, so we need methods beyond 
load () and save () in both the 
GUI code and in the business objects for these more complex interactions 
between GUI and backend.

Ian
-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

pgpB0KsMPS43N.pgp
Description: PGP signature