gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] module interdependency


From: Ian Haywood
Subject: Re: [Gnumed-devel] module interdependency
Date: 06 Jul 2003 19:31:39 +1000

On Sun, 2003-07-06 at 09:04, Horst Herb wrote:
> After a long break I finally find the time again to do some work on
gnumed.
> 
> I am a bit puzzled by the changes, find it hard to get back into it.
> 
> Module interdependencies appear to have grown wild a bit, with no
> clear 
> separation of GUI and "common", example "gmPlugin.py".

gmPlugin provides the generic plugin capacities (loading, unloading,
etc., naming) This class does not depend on wxPython libraries.

Indeed the following classes do, I thought they had been moved to
client/wxpython/gmGuiPlugin.py, certainly they should be.

AFAIK, the separation between python-common/ and wxpython/ is otherwise
adhered to.

> Maybe there is a good reason for all this, but maybe we should refocus
> strategy and clean up code before we continue implementing.
Agreed.

Two points I think we should discuss:

1/ single plugin architecture, with cascading notebooks and optional,
configurable split screen design. We could consider going "the whole
hog" and using XRC [http://www.wxwindows.org/manuals/2.4.0/wx478.htm]
to express the interface in XML, thus allowing essentially total
configurability. We will probably end up with one interface design for
each developer, IMHO, this is a Good Thing.

2/ backend communication. The current solution appears to be "internal 
middleware" using Python objects under gnumed/business. It is unclear
how compatible this code was with any move to XML-RPC or whatever, or
even if we are going to make this move.

Also, this appears to involve a lot of repetition, rewriting the
allergies interfacing code with simple changes for medications, past
history, social history, etc.
This there any way of abstracting this out?, as most aspects of clinical
history seem to be lists of dictionaries for each patient, the
dictionary reflecting columns of a particular table on the backend. I
know Horst once mentioned something to do with this. 

Even if we stick with the status quo, we still need a clear *documented*
explanation if how it works. and commitment from all developers to stick
with it, at least until 1.0 

Ian






reply via email to

[Prev in Thread] Current Thread [Next in Thread]