[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Forms layer (was: Re: web frontend/patient singleton)
From: |
Ian Haywood |
Subject: |
[Gnumed-devel] Forms layer (was: Re: web frontend/patient singleton) |
Date: |
Mon, 31 Jan 2005 07:52:42 +1100 |
User-agent: |
Mozilla Thunderbird 0.8 (X11/20041012) |
Karsten Hilbert wrote:
Can you give a minimal self-contained example ? It sounds OK
at first sight but I am not quite sure how it maps to
form_data.
This gets us back to field types being at a conceptally higher level --
"patient", "drug", instead of just "int" "bool", "string", and
(IMHO) allows sensible auto-construction of some, hopefully, most, form GUIs
This sounds appealing, yes. We need to keep in mind, however,
that we'll need to be able to store filled in forms, too. And
do it in a way to later be able to say "reconstruct this form
and offer it as defaults for a new form instance" - which is
why storing binary form instances isn't sufficient.
Yes, serializing compound types is not easy. Two options:
- store them as multiple entries with slash notation, viz:
drug/1/name: amoxycillin
drug/1/form: syrup
drug/1/strength 50mg/ml
drug/1/dose: 5ml
drug/1/frequency: 1-0-1-0
drug/2/name: ibuprofen
drug/2/form: syrup
drug/2/strength: .....
OR, as the number and composition of compound types is agreed upon a priori
between client and server,
a fixed association with a particular backend table, and its PK, can be made,
so the client can have a
fixed procedure for re-constructing it via that PK (or list of PKs). In our
client, this is by instantiating the appropriate
business object(s), Other clients can do as they please, but they are working
with the same backend.
So form_data has
fk_form integer references .....
fk_form_field_defs integer references ...
raw_data text, -- for basic types
fk_compound [] integer, -- PK(s) of appropriate table for compound
types.
Ian
signature.asc
Description: OpenPGP digital signature
- Re: web frontend/patient singleton was: Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005), (continued)
- Re: web frontend/patient singleton was: Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005), catmat, 2005/01/29
- [Gnumed-devel] Re: web frontend/patient singleton, Ian Haywood, 2005/01/29
- Re: [Gnumed-devel] Re: web frontend/patient singleton, catmat, 2005/01/30
- Re: [Gnumed-devel] Re: web frontend/patient singleton, catmat, 2005/01/30
- Re: [Gnumed-devel] Re: web frontend/patient singleton, Karsten Hilbert, 2005/01/30
- Re: [Gnumed-devel] Re: web frontend/patient singleton, Ian Haywood, 2005/01/30
- Re: [Gnumed-devel] Re: web frontend/patient singleton, Karsten Hilbert, 2005/01/30
- Re: [Gnumed-devel] Re: web frontend/patient singleton, Karsten Hilbert, 2005/01/30
- [Gnumed-devel] Forms layer (was: Re: web frontend/patient singleton),
Ian Haywood <=
- Re: [Gnumed-devel] Re: web frontend/patient singleton, J Busser, 2005/01/30
- Re: [Gnumed-devel] Re: web frontend/patient singleton, Karsten Hilbert, 2005/01/31
- Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005), catmat, 2005/01/28
- Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005), catmat, 2005/01/28
- Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005), Karsten Hilbert, 2005/01/28
- Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005), Karsten Hilbert, 2005/01/28
Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005), Karsten Hilbert, 2005/01/26
Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005), Thilo Schuler, 2005/01/26