[Gnumed-devel] (no subject)re: reverting

[syan tan]

Nope. Your patches are of high quality. So are Ian's. Now, the
*concepts* within Syan's code may well be of high quality,
too, but that massive commit was poor.


> > IMO the most important rule is that you have to think before commiting.
>  
----------------



As I said before, I'm in the process of reconstructing the old directories by 
downloading each previous versioned
file in a "revert" branch, which can be overlayed over the client main branch;  so if the consensus is to 
restore old files, just let me know, and I will re-commit the old files. 
I can't restore the comment messages easily, unless I individually commit the old files, and copy in the old comments.




Unfortunately, the cvs doesn't distinguish its own commit comments from the rest of the program, 
so any changes in these areas will cause a commit and comment change: much of the commit 
was new files, and gmClinicalRecord, gmDemographicRecord, gmEditArea, gmGP_PastHistory, gmGP_Allergies,
gmDemographics. The others had no or little code changes. I massed committed , 
because this was more likely
to commit working code. The code was working, (albeit with a lot of debugging 
output, and non-fatal
error messages, and only when the postcodes.au.sql file was loaded into the demographica tables). 
The code was also manually synced several times at home, and just before I committed, so that old patches were integrated in. As for altering previous functions, I made some apparent variable naming error  corrections
to the custom match providers in gmDemographicRecord , because they weren't 
working when I tried to use them, but
otherwise it was minimal to get the client working, 

The point of the exercise was to produce a client that called the modules in 
the business directory ( and existing code - Karsten's or Ian's - if the 
functionality was there), and preserve the existing client UI behaviour ( 
mainly the
demographic search, and top panel ui update on patient selected).

I'm not so sure it helps to understand the code by reading the comments; so far 
, I find it's easier trying to guess
the functionality from the method name and look at examples of how it is called 
from within the existing code text,
and then trying to make the call work. Comments don't help that much in 
understanding the gui framework either:
I relied on remembering when Karsten changed gmEditArea from a name switched conditional construction to subclasses, 
and finding the subclasses being used within the patient directory gmGP_ files.

There are parts of the gui which I don't understand, like the StikoBrowser, and 
EMRTextDump ,because I don't really know what the intended purpose is, and I've 
not intentionally tried to change these modules at all.

The client behaviour that has been committed in is:
login as test-doc.  Choose first menu item and patient select. Choose the new 
button at the bottom of the
gmPatientSelect tab. Switches to gmDemographics, 
and  produces a blank patient with dummy names ( yes , I did change the sql in gmTmpPatient,
to just insert into v_basic_person , as this worked easily ). Edit the patient name, sex, date of birth. 
Select an address type ( home, work ) and edit the number, street , suburb, postcode. Street , suburb and postcode
fields have PhraseWheel functionality ( if the suburb table is loaded).
Press add address to add the address. Can add another address of a different
type. Double click an existing address in the list of patient addresses to edit 
the address. click delete address
to remove address. 
Click save to save the person. 

Use either the top panel patient search, or the gmPatientSelect to search to find a patient. Switch to clinical 
to and view the allergy and past history edit areas to make updates in these areas. Past history edit area will
only display active and past significant problems ( unselecting active and 
significant , currently loses these
the past history item in the database, because the spec didn't have a view 
non-significant inactive history list!)

Significant active history will get displayed also in the summary list.

Currently , updates to allergies will appear in the editarea list, but will 
only appear in the top panel
if the patient is re-selected ( by pressing enter in the focussed patient 
select field in the top panel).

Really, not much has been done, because the gui (as a proprosed functional 
client) is ahead of the business layer.
If the current minor functionality added is acceptable, then someone should 
work on a basic prescriptions business
object , and possibly a vaccinations object. Someone could re-do the allergies 
and past history business objects
I wrote, but I think trying to get a small part working perfectly rather than 
adequately and moving on to the next
part, is a waste of time. This could be done when the other parts are 
adequately done.
P.S. my definition of adequate is data in , data displayed, data editable, data 
out.
 
On the other hand, I am quite prepared to take 2 steps back again, because I've already done this about 3 times before,
and it isn't all that traumatic.  ;)