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

[Karsten Hilbert]

>> Or Liz who has posted
>> meaningful lab selections and is working on getting them
>> codified at some point
> where are these?
She posted them a few weeks back.

> 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 ).
None needed. There's a German saying "Where there is planing,
there will be shavings (wood chips ?)."

> Some questions:
> - The demographics entry gui , I thought, reached a satisfactory standard
> but it's also been "retired" , why? Is it too AU specific?
1) yes, it did work
2) I deliberately refrained from complaining about not being able to
   comprehend the concepts or judge the mechanics as elegant
   (that's my problem, after all) but resorted to accepting it
   as what we have now
3) every now and then little bits of backend/middleware had to
   change
4) due to my lack of comprehension I couldn't and didn't fix
   the demographics entry GUI
5) no one felt committed to being responsible for fixing it
6) hence it fell into disrepair - classic bitrot - but it was
   *not* deliberately deprecated !

> -  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?
If you write, maintain and support it - or find people to do
so - you are perfectly free to do such.

> - other "versions" of the client.
Fine by me.

> The reasons for the business objects  and the  pycommon utility  
> framework stuff,  is that
> 1. hiding  rapidly changing SQL scripts  behind a  much slower changing 
> , ( preferably never changing)  data access method interface
ACK

> 2. place validation code within data-access objects;
yes

>  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.
Yes. For clarification: intra-client doesn't use NOTIFY-LISTEN.

> 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
Quite actually a nice description :-)

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


> - So what's the go on writing  throwaway , boring  script clients ( e.g. 
> at first,
You are welcome to do so. You can use business objects, too,
if they are of any help.

> without any attention to sequential or otherwise consistency
> ( so no inter-client signalling) ) ?
You can't avoid the consistency or signalling to happen since
we put it in the backend. But you can chose to ignore the
signals. If the code tries to break consistency the backend
will (should) complain due to constraints. There are missing
constraints because PostgreSQL doesn't have database asserts.

We even have "throwawy" script clients already. Think
document import, German lab import for examples.

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