|
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 |
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.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 don' t think it's hard to change though. Some while ago , I was trying out a multiple child window java client usinga 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).
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.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.
[Prev in Thread] | Current Thread | [Next in Thread] |