Re: [Gnumed-devel] keep testing, or add to main source?

[Ian Haywood]

On Wed, 08 Oct 2003 02:11:55 +1000 
>1- widget placement/alignment is still somewhat ugly and therefore not even
>at the same level as the current (Richard's) EditArea.
Easy to fix, as I have mentioned, GTK styles can fix much of the "aesthetic" 
matters. 

>4- As far as I understood the consensus for backend interaction was that the
>GUI should interact only through business-objects with the backend, not by
>way of direct sql-queries. Maybe we should separate out  the part that deals
>with the backend to a business-object. 
This is the biggie. Unfortunately Syan has ploughed ahead with out using the 
considerable body of database infrastructure already developed, without giving
a  clear reason.

We definately should be using gmPG etc. to communicate wih the backend:
that's easy to fix.

More problematic is the higher-level business objects in gnumed/client/business.
Syan, it is important to remember that the GUI won't always be communicating 
with 
a SQL database, drugs in particular. We need to support MIMS, which isn't SQL 
at all
(some form of XML RPC apparently, I've made a request for an API spec)
and AMIS (the German drug database) which has a totally different schema to 
drugref.org.

Also, prescribing will involve a lot more programming logic than just inserting 
to a table,
such as checking interactions, allergies, etc., etc. Originally (i.e when I 
first contacted Horst
back in 2001) we planned to use server-side triggers to do all this, but for 
the reasons above
this is impossible: it has to be done client-side, in Python)

The same goes for demographics and contacts. Demographics may, and contacts 
probably should, 
be run as centralised LDAP servers, again business objects are needed to 
abstract this out.

The exception to this rule is gmClinical: it's difficult to imagine why you 
would try
to run this on LDAP or XML, so direct GUI-to-SQL tricks are possible.
(and probably desirable: writing a business layer for this would take ages)

Writing business objects is easy, albeit slightly boring, especially with gmPG 
wrappers, most functions 
can be a few lines:
        def _getDOB(self):
                # FIXME: invent a mechanism to set the desired format
                cmd = "select to_char(dob, 'DD.MM.YYYY') from v_basic_person 
where i_id = %s"
                data = gmPG.run_ro_query('personalia', cmd, None, self.ID)
                if data is None:
                        return ''
                if len(data) == 0:
                        return ''
                return data[0][0]

In this sense they are really "named queries" 

At this point, we need to agree on rules for the business object<->edit area 
interface to
try and simplify things. 

let me put this as a tentative proposal:
        - the editarea base class is put on a crash diet: it doesn't know or 
care about backends, and
it exports get_widget (). As a convience, it can export itself as a dictionary 
(__setitem__ and __getitem__
for manipulating widget values directly.

        - the business objects provide specific MatchProvider descandants 
(PostcodeMatchProvider, DrugMatchProvider, etc.) which are tied to the 
phrasewheels. It would nice to generalise this,
but hard. For example, drug name matching will first look at gmClinical for 
commonly prescribed 
medications, *then* to drugref or whatever. Ideally drug name matching would 
also  depend on 
what the patients diagnosis this (which isn't even a field in that edit area)

        - the MatchProviders for one business object are all provided with a 
Context object (really just a dictionary), which the calling class is not 
allowed to inspect, so they are allowed to share context.
         
        - most of the work so done by gmDispatcher handlers in the plugins 
(loading values
for a new patients, saving it via buttons) 

Ian Haywood

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