Re: [Gnumed-devel] Gui-Designers was the id_name debate

[scaredycat]

> Or Liz who has posted
> meaningful lab selections and is working on getting them
> codified at some point
where are these?


> Yet,
> other people have not done anything to actually help.
There's probably a natural tendency to equilibrium here; order might
be created in one place, at the expense of increased entropy elsewhere,
with net entropy. Sometimes the locus of entropy is near the locus of
order creation, which can be unfortunate, but isn't entirely deliberate.
(If that's an apology, take it as one ).

I'd agree with Richard about programming being boring overall, especially
when isolated from its social side effects. 

Some questions:
- The demographics entry gui , I thought, reached a satisfactory standard
but it's also been "retired" , why? Is it too AU specific?
-  wxPython 2.5 has a Gridbagsizer, and a abstract  base class for  
listbox/comboboxes,
a different event system : is there going to be a wxPython2.5 stream 
for  clients?

- other "versions" of the client. The client  API can be difficult to 
remember.
I once did a project with another guy, and there were supposed to be 3 
members. His coding
style was a lot different : a bit like embedded SQL ; he made no  
attempt at model view controller
separation. Because we had one less member, I did a framework , because 
the schema
was fairly simple, a generic table editor class ( yes, with MVC 
separation,  doh!) that handled inheritance but not foreign keys.
This was all done in java . The way the other guy did it, it would have 
been boring to code,
but I think he would have spent a lot less time debugging, and because 
it had an ultra-simple
style, it would have been easier to understand,  navigate, modify.
The reasons for the business objects  and the  pycommon utility  
framework stuff,  is that
(I think)  :- 
1. hiding  rapidly changing SQL scripts  behind a  much slower changing 
, ( preferably
never changing)  data access method interface  ( a bit like how 
java/python standard library packages hardly change,
only obsoleted (when they get too many complaints?) )  ;
2. place validation code within data-access objects;
 providing for  a remote event system ,
3. hiding the SQL "LISTEN / NOTIFY"  postgres commands
for communication between clients  behind a event/signal  framework, 
which is also used for intra-client and well as interclient comms.
4. providing "transparency" for data-access to a simple multi-database 
system, not full  federation of heterogenous databases as such,
but a table granularity partitioning of a general conceptual schema 
across a homogenous distributed database
system 
(  this is another way of  combatting  boredom for fun and profit, see 
how many  buzzwords  remembered
from "a  distributed database  systems"  subject can be strung together 
to form an IT confidence imbuing statement).
The multi-database is apparently for separation of concerns of the 
schema as separate services,  possibly because 
for security or applications usage-pattern reasons,  it would be nice to 
separate demographic and clinical services even physically
on separate machines.

- So what's the go on writing  throwaway , boring  script clients ( e.g. 
at first , without any attention to sequential or otherwise consistency
( so no inter-client signalling) ) ?  The trouble here is that a) it's 
boring b) the effort
is likely to be wasted c) fine-tuning , especially of validation, can be 
boring  d)  it's likely to be so specific for a particular
locality , that it might  say only capture the attention of say 3 
computer literate oz docs who don't want to pay ongoing
fees to Ozdoc (just a joke) , and want their own simple script client 
code to break and fix when they've got nothing to fix around the house.