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

[syan tan]

Ian Haywood wrote:

> 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.
Least resistance path I suppose. I haven't tried to read up the business 
objects yet.

> 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.
>  
gmEditArea3 is not hard to do because it has no API to program to: it 
would be nice to discuss the formats going
to be used (  other drug database APIs (is there a standard?) , AMIS 
api,  LDAP  and  a simple example of how
demographic data is going to be stored on it,  and how is a messaging 
API going to fit in with all this? ( Is it Jabber transport, and
HL7 v2.x  ?)  Can one leave security APIs out, and then worry about them 
later when things are working?
Is the demographic business objects going to be one interface and 
different implementations ? So what's the common interface,
and what about making easy enough to generate a prototype sql access to 
arbitrary structured  tables , so development
isn't stalled on tackling issues such as learning above APIs.

> 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.
>  
get sql contacts working first?  Doesn't openLDAP have a SQL api? if so 
, what is the standard
schema for the SQL api , then can model the test SQL contacts schema on 
it? (? oversimplified?)

> 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]
>  
Is there any point in trying to get around the boring part?  What about 
writing a interoperability tool to convert arbitrary schemas from
one form to another? (e.g. from the auto-generated schema, to whatever 
schema is easiest to translate or best to store)

> 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.
Then someone should define the interface for the dbobjects , and some 
work can be done for the simplest implementations ( custom arbitrary sql 
?auto-generated
tables/views )

>         - the business objects provide specific MatchProvider descandants 
> (PostcodeMatchProvider, DrugMatchProvider, etc.) which are tied to the 
> phrasewheels. It would nice to generalise this,
> but hard.
But it already works with just dumb text matching for those 2 cases ( 
except when matching indicated drugs, but then a  narrowing indication 
table could be used)

> 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.
> 	 
please elaborate this concept (in an example); why ?

>         - most of the work so done by gmDispatcher handlers in the plugins 
> (loading values
> for a new patients, saving it via buttons) 
>  
Why gmDispatcher and not just listctrls bound to editareas? Why the 
indirection?

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