Re: [Gnumed-devel] demographics editor

[Karsten Hilbert]

> the tabbed patient idea is not too much different from multiple clients 
> or  multiple child windows in a MDI frame ,
> just that it's arguably easier to find the button to switch the 
> patient.  You could also limit  the number of patient tabs,
> like the sensible practice of opening up 4 client windows and making 
> sure you're never tempted to open up anymore.
> 
> If a patient panel inside a tab is a view on a particular patient 
> object/model , either having a reference to the patient object or
> the id of the patient, it shouldn't be a problem, even with the current 
> signalling mechanism to notify the right tab if the signal
> carries the id of the patient.  And if  signalling was per patient, as 
> in model-view  / listener / observer pattern, it would remove
> the id test.
> 
> In a webapp , if each tab is a separate form with a readonly field with 
> an id value specifying the patient, I think it would still work.
> OTOH, it's probably not applicable, because  some browsers allow 
> multiple windows as tabs and others don't, and this is
> transparent to the application.
You are sure right it can be done. However, do you notice all
the IFs, COULDs and SHOULDs in there ? I am so unconvinced of
my programming discipline that I rather remove all of them by
the sweepstakes rule "one client one patient" and be done with
that.

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

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.

Opinions, anyone ?

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