[Top][All Lists]
[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 .
- [Gnumed-devel] re: gui/schema,
sjtan <=