Re: [Gnumed-devel] Specs

[Tim Churches]

Ian Haywood wrote:
> Ok, maybe more like $2-worth now, please bear with me.
> 
> I think we can have a better middleware. This is largely a 'technical' matter 
> and in some ways orthogonal to the problems
> of requirements/specs/etc. But historically I think it's where we went wrong, 
> back in 2000-1 we were running along merrily
> with coding and designing basically in parallel, then things came unstuck as 
> development basically halted for 18 months
> as we had no agreement on how to actually shift data from backend to widget 
> and back. On unfortunately is wasn't something we
> can say "each to his own": we needed to agree or we might as well have been 
> writing separate clients.
> 
> Our current middleware comes unstuck because it does everything twice: 
> middleware objects need to be manually defined
> even though 90% they correspond to stuff in the backend. They don't do 
> error-handling well (I want to be able to
> write error-handling *once* and never worry about it again, I don't want to 
> check for errors *every* *single* *time*
> I call the middleware layer!), and inserting new rows is harder then it 
> should be. Working with 'advanced' postgres
> features like stored procedures is harder than it should be, and so 
> under-utilised.
> 
> I'm sure you've guessed where this is leading. I have written a basic 
> extension to my python-postgres adapter to allow
> access to the database 'pythonically', so long as certain naming conventions 
> are adhered to (mainly ones that we
> already adhere to)
> 
> example.
> 
> l = sql.find_patient ("Smith") # runs the backend prepared query 
> find_patient, returning row instances
> p = l[0]
> a = p.allergies # runs select * from allergies where fk_patient = <pk of 
> patient>, which is cached
> 
> del a[0] # runs delete from allergies where pk = <the pk of that row>
> 
> a.new (reaction="rash", drug="penicillin") # insert into allergies (reaction, 
> drug, fk_patient) values ("rash", "penicillin", <pk of patient>)
> a.do_something (foo) # calls the prepared query do_something (<pk of 
> allergy>, foo)
> p.update () # commits the above changes in a single transaction by traversing 
> the local object tree.
> 
> all this without defined specific "allergy" and "patient" classes, however 
> such classes can be defined and will be used automatically if you
> want some client-side functionality.
> 
> class allergy (PgRow):
> 
>       def do_something (self, ....):
> 
> but we don't have do do any "bureaucracy" when defining a new business layer 
> object.
> 
> In many ways this is the culmination of what the current business layer has 
> been evolving towards for some time,
> the biggest difference this that it throws error exceptions, which simplifies 
> things a lot.

Yup, this is the way forward - the creation of a meta-application
toolkit. For Web app development, Ruby on Rials, and more recently its
Python cousins Django and TurboGears have and are becoming hugely
popular, because they abstract away a lot of the tedious details of
application construction - at all level - backend, middleware and
front-end - and let you focus on the tasks in hand. perhaps Gnumed2
should be a similar toolkit for the construction of medical
applications, rather than a specific application, because it is clear
that au-GNUmed, de-GNUmed, ca-GNUmed etc etc all need to be different
beasts.

Anyway, we are about to embark on the final round of development of
NetEpi CaseMgr prior to version 1.0, and that's the way we will be
taking it, except that NetEpi goes one step furher - no programming,
just point-and-click set-up of epidemiological data collection
applications - which is a much more constrained domain than that of
general practice clinical applications, of course. But very high level
toolkits for specific domains are the way to go. And Python is a damn
good language to build them in. PythonCard is a good example of a
highish level GUI toolkit - but maybe GUmed2 needs to be at an even
higher level - unlike TurboGears and Django and Ruby on Rails,
PythonCard doesn't do database binding or business logic. But maybe
consider Qt4, rather than wxWindows - far less grief, I am told,
although the open source binding for Qt4 (which is now open source on
all platforms) are still in the works, I think.

Tim C