[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Gui-Designers was the id_name debate
From: |
scaredycat |
Subject: |
Re: [Gnumed-devel] Gui-Designers was the id_name debate |
Date: |
Thu, 09 Sep 2004 09:22:35 +1000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 |
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.
- Re: [Gnumed-devel] Gui-Designers was the id_name debate,
scaredycat <=