[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] update on some test work.
From: |
Ian Haywood |
Subject: |
Re: [Gnumed-devel] update on some test work. |
Date: |
Tue, 4 Nov 2003 16:27:05 +1100 |
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