gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] re: gui/schema


From: sjtan
Subject: [Gnumed-devel] re: gui/schema
Date: Thu, 22 Jul 2004 03:24:26 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616



Yes, please syan, do explain.

I'm just a little peeved at how development progresses , but it's getting there now. The client does look better as either 2 looks , Richard's layout or multiple tab layout; the backend schema gets changed quite a lot, when it might have been possible to do it with less features in multiple versions. Everytime I look at Richard's exposition, I think it can be almost be done in a week, if there was a one to one mapping, and maybe a slightly more commercial package like qt designer , which looks like it's written for
quick hacked up apps (  e.g. database connected widgets) was used.
Most of the effort has been towards building a fine infra-structure, when maybe the specific use cases could have been tackled first. I just had a play with eclipse EMF framework, which is a java based framework for generating data objects, edit adapters, and editors for file based applications that use eclipse as a application platform ; Protege looks similiar, also java based, but I think the editors aren't as customizable; gnumed is a hand designed relational schema, instead of generated from some sort of object model, so EMF, Protege, ojb, python ModelingFramework , etc.. aren't very useful; Hibernate could possibly be, because it has xml configuration files, but there are some relations , such as linking many-to-many tables with attributes on them in gnumed, which might cause problems, and making the xml configuration actually work is painful to debug; also, hibernate is not gnu and probably too commercial, overhyped, not python, designed for server programs, too slow for complex schemas and large composite objects , like an identity object navigatable to all its clinical info objects. Then there's the feeling that all the schema information is available by examining pg_class and pg_constraint , and it would be possible to specify some tables as root objects, others as lookup objects, which relationships are containment ( i.e. delete cascades to the kid tuples) , and you just wrote a small program for that , which say, might code generate the python persistence objects , you get rid of a lot of tedious or-mapping work and repetitive CRUD scripts that need time-wasting debugging. Then the problem of user interface looks also like a problem of lack of software components , that possibly wxDesigner ( commercial ) might give, after the authors of wxWidgets have dazzled those scummy open source scavenging developers with its scope, but sad lack of tools. Richard's entry forms look like they're all the same, but with a differently configured lookup field here, a comma-separated multi-lookup field here, and some action modifying checkboxes here. The actual actions are pretty repetitive too : either the literal value of the field, a lookup id, a few look ids, are put and gotten from table fields; a bunch of data is reorganised and put out to a stream in a different order with extra formatting information that fit a protocol of
other programs ( e.g. tex) .
It's really boring, the tools have been there for donkey's years, and we can't find them and use them!!
Maybe we should start a MUMPs customization sub-project .








reply via email to

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