[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?

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]