Re: [Gnumed-devel] Two patches

[Karsten Hilbert]

> >fields by phrasewheels there's no way in the world it can
> >deduce from the DB definition how to attach a phrase matcher
> >to it or how to set up keyword popups. 
> That would have to be a specific type. The "entity" type is an example,
> our wxpython client can choose to use a phrasewheel linked to a matcher.
Which then needs to be precisely defined which, ...

>> however, should perhaps be kept separate from
>> the generic field definition as it is application specific.
>                                        ^^^^^^^^^^^
> 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
to be more specific you are writing backend tables that *mix*
frontend specific support with generic data. Quite some time
ago I argued with Syan that that wouldn't be desirable when he
intended to store clinical data as structured free text when
it should be put into dedicated tables.

However, there's nothing wrong with targetting a forms
*middleware* at a given client. Neither is there anything
wrong with storing frontend specific data in a backend (after
all, what else is cfg_* ?) I just happen to think there might
be value in keeping it separate from the generic data.

I have the feeling that once we factor out form_field_gui_defs
from form_field_defs we might find things clearer. Eventually,
clinical.form_data might need an fk_form_field_defs.

I also wonder whether form_defs should not have a
fk_default_queue rather than an url. Or whether that is
really the right place for that association ? But hey, no big
hassle.

> >Also, I would not let the form code access a demographic
> >record entity. That is way too application specific IMO.
> In writing the AU forms I found having access to
> business layer objects quite powerful, and a lot simpler than
> passing each individual element (patient_name, patient_street, paitent_city,
> doctor_name, doctor_street, .....) It also aids form flexibility,
> so the same widget could drive both a paper and and a HL7 referral form,
> for example, impossible with "granular" fields.
I don't like this part at all (although I certainly agree it
is very powerful - but also dangerous -- data executing
something in the application is scary -- a form might walk up
the inspection tree and send out passwords, data of other
patients, whatnot). This would make the form definitions
GnuMed reference client specific *shudder*. Data "easily
accessible to outsiders" should be passive IMO...  I really
really want a web client or Qt client or whatever to be able
to pull form templates off the database and be able to fill
them in without having to reimplement something like
cDemographicRecord.

Other than that :-) this stuff looks very good to me !

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346