Re: [Gnumed-devel] module interdependency

[Karsten Hilbert]

> 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.

Good idea but IMHO *all* of gmPlugin should move to
gmGuiPlugin. Why, yes, it's generic non-gui code (in class
gmPlugin anyways) but, hey, honestly, what use is it going to
be outside the GUI, nay, even outside this wxPython client
implementation ?

> AFAIK, the separation between python-common/ and wxpython/ is otherwise
> adhered to.
The other offender is gmPG which does have a dependancy on
wxPython. The code is in request_login_params_gui_wx() which
may or may not be movable to gmLoginDialog.

> 1/ single plugin architecture, with cascading notebooks and optional,
> configurable split screen design.
Maybe now I do get your point. You don't want to abolish
Richard's rich (no pun intended) clinical notebook plugin but
you don't want to handle a special type of plugin within that
notebook plugin but rather hardcode it's layout ? If you plan
on abolishing the functionality Richard put forth in fairly
close to how he put it forth than you'll have to travel down
*that* road without me.

> 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.
IMHO gnumed/client/XRC/

> We will probably end up with one interface design for
> each developer, IMHO, this is a Good Thing.
No. Ending up with one interface per user is a Good Thing (not
that I consider that as a 1.0 or even reasonable goal).

> 2/ backend communication. The current solution appears to be "internal 
> middleware" using Python objects under gnumed/business.
IMHO yes.

> It is unclear how compatible this code was with any move to XML-RPC or 
> whatever,
I try to conceptualize calls to that API in a way that it will
be readily apparent how to port it to other transport
mechanisms (of which it should be fairly independant). Through
coding I have come to the habit of *accessing* the EMR by
__getitem__ handlers (EMR = pat['clinical record'] and friends) and
direct calls to methods for storing stuff in the database (one
reason for this being that it's cumbersome to pass parameters to
__setitem__ handlers {EMR['current episode name'] = 'DRUG
fracture 7/02'}).

> or even if we are going to make this move.
I'd still consider it desirable. Someone please check in a
working server with a reasonable subset of functionality (say,
4-5 FPs).

> 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?
Now *that'd* be real nice.

> , 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.
Sort of yes but the rub is in the "*a* particular table" part.
It is not *a* table. Clinically meaningful entities (which
should IMHO be the client-side API) need not map *1:1* onto
storage entities (say, tables). This is another way of
reiterating my comments on the difference of a business vs. a
database transaction re the scope of GUI plugin to database
chunk committal.

> Even if we stick with the status quo, we still need a clear *documented*
> explanation if how it works.
What exactly do you need to know ? I can do a writeup. But
someone else must move it from the docs TODO into the docs
SGML source.

> stick with it, at least until 1.0
That's a plan.  XRC post-1.0, too ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346