[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] another try:
From: |
Ian Haywood |
Subject: |
Re: [Gnumed-devel] another try: |
Date: |
Mon, 20 Oct 2003 19:44:37 +1000 |
On Mon, 20 Oct 2003 17:40:37 +1000
syan tan <address@hidden> wrote:
> I was thinking of a hybrid configuration file ( in xml at the moment;
> perhaps yaml might be better, but a python xml parser already exists) ,
Python parsers for yaml exist too!
IMHO, YAML is a lot easier to use, as a YAML document is transformed
into a Python data structure in one line of code, the same in XML takes ages.
> Then the same thing goes, define a type of widget and map it to a model
> element; e.g.
> individual fields are textboxes, checkboxes, or spinners (for
> date/time and numbers);
Again, you are cutting out the middleware layer.
This doesn't mean your idea isn't interesting (I think it is), but you need to
relate it back to what's
already been done somehow. Even if that means dumping some code, you need to
be clear about
that, otherwise we just sink further into confusion, with 10 different ways to
access the database.
> here's the beginnings of a model definition that maps the relations of
> the current gmclinical.sql database. (There's a variation in vaccination
> because of its use of integer arrays as one-to-many references, which
> doesn't work on my postgres. )
we should change this to a proper linktable ASAP , as has been said.
> If user interface definition by configuration with either xml or yaml
> files is possible, then communication could be the same as well, as well
> as data import/export transformations ( not sure if this pie-in-the-sky
> until it's attempted).
I agree, certainly dead-tree forms should be defined in YAML
(I have some code for this, just trying to make it CVS-worthy)
Ian
--
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42 C063 28FC BC52 E750 652E