[Top][All Lists]

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

Re: [Gnumed-devel] demographics editor

From: sjtan
Subject: Re: [Gnumed-devel] demographics editor
Date: Fri, 17 Sep 2004 09:32:19 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

Just today I had a similar issue crop up:

a) After starting GnuMed and before selecting a patient we
  currently have no active patient.
b) After starting GnuMed and before the user had any chance of
  selecting a patient the initially raised plugin tries to
  update itself.
c) Since there is no patient it cannot update and may hang
  unless precautions are taken.

Mainly, there are three solutions:

1) in every plugin check for active patient and return if None there
  - cumbersome,
  - prone to forgetting,
  - lot's of checking at every tab change for a rare corner case

2) declaring a special widget that doesn't need a patient to
  be the mandatory widget being raised initially
  - just doesn't feel right technically (special values should
    be avoided where possible, not created),
  - doesn't sit well with the idea of loadable plugins

3) take the design decision to *always* load a patient, even
  before the user selected one
  - sounds cleanest, technically
  - may need getting used to by some while not by others
  - can still fail -- when there's not a single patient in
    the database in the first place ...
  - but this can be alleviated by a once per session
    check that fails once per installation lifetime, then
    creates a demo patient (uh, uh, special value, I know)
    and thereafter always succeeds

I probably don't fully understand what's said here, but I think the problem is resistance to change when there had been no original plan to have a multiple patient gui client, and therefore it was built in to handle just one patient.
I don' t think it's hard to change though.
Some while ago , I was trying out a multiple child window java client using
a third-party or mapper to see if it would work. It relied on loading all the information at once into a single patient object tree/document, which was a bit slow with the o-r mapper and saving was quite slow as well. I think I gave up , due to lack of interest, plus it wasn't really mapping to the same schema ( as well as concerns about the free ,as in beer, of the o-r mapper).

When there was no patients, there was no child windows , and no patient objects, so it didn't stop the main frame offering find patient and exit option on the menubar. Find patient would bring up a special child window for finding and selecting patients for opening. This would be option 2) above. Where the first tab is the find patient widget, and other tabs individual patients open. Currently, the loadable plugins load at the tab display area with a context menu. If option 2) was chosen, the gui gesture can still be the same, but the plugin instance is loaded/unloaded for each open patient, which is just a conceptual difference for the user (closer to what a plugin really is, not an individual gui feature object, but the class which defines a feature for a gui).

OTOH, it's been said a few times that a patients loaded history could be kept , and some sort of drop-down list or bookmark list could be used to swap the patient being viewed, and just have the current gui/model setup, but cache loaded patient data per patient , and maybe make it write-through for updates ( updates written to state variables in the domain objects
as well as straight to sql , and views are of the state variable values).

Currently we are at 1) except that we are lacking the checks
:-)   Not that I try to advocate 3) here (though I like it and
can attest to it being used in thousands of installations). I
just want to point out what sorts of fundamental problems can
be avoided by taken simple yet stringent design decisions.

I think I'm not used to seeing 3) , being used to document centric applications such as mail , word processing, spreadsheets, and local emr apps that treat patient records like files/documents to be open / closed.

reply via email to

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