Re: [Gnumed-devel] demographics editor

[sjtan]

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