Re: [Gnumed-devel] Two patches

[Ian Haywood]

On Wed, Jan 26, 2005 at 06:59:44PM +0100, Karsten Hilbert wrote:
> > Well, yes, I'm writing a forms layer for gnumed, not anyone else ;-)
> Well, no :-)   You are writing a forms layer specific to a
> given instance of a client, eg the Python reference client. Or
That's true. But the forms already contain Python snippets (which you
agreed to AFAIR)
The forms are dependent on the *middleware APIs* not the GUI layer. We
can still have Qt and web clients -- so long as they are in python.
I'm not sure why we would want to use another language, I don't see
why the forms layer design needs to be hobbled because of Syan's
IMHO just plain silly decision to use Java.

Moving back to having a large number of fields which are simple types
(boolean/int/text) is possible, and which allows portability away from
our middleware APIs and this makes form_field_defs too lowlevel to
produce a sane interface automatically.

This gets back to the concept of a "form type": which refers to the
whole complex of fields accepts by that form, which the client can then
use to select its data entry widget as a whole unit. It's not as
flexible, but it does do the job and does keep middleware-specifc stuff
out of the backend.
> I have the feeling that once we factor out form_field_gui_defs
> from form_field_defs we might find things clearer.
How would you split this table? What would be left in form_field_defs?
> Eventually,
> clinical.form_data might need an fk_form_field_defs.
Yes.

> fk_default_queue rather than an url. Or whether that is
No, it's a specific e-mail address. The "queue" is generally implicit in the 
engine: latex always printed/faxed, HL7 etc. always e-mailed.


Ian

pgpGwrsaKtcv5.pgp
Description: PGP signature