Re: [Gnumed-devel] Two patches

[Karsten Hilbert]

> > 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)
Duh, I completely forgot that. I did agree to that (actually,
I think I even proposed it...) I do have an excuse, however ;-)
I always wanted them to be tagged by a domain identifier such
that such Pythonisms can be detected. Also, I think I wanted
them to be either generic Python code (eg not GnuMed specific)
or else run those GnuMedlets inside a code tree jail or
something...

> The forms are dependent on the *middleware APIs* not the GUI layer.
A good point.

> We
> can still have Qt and web clients -- so long as they are in python.
Or implement the middleware API.

> I'm not sure why we would want to use another language,
Not us, perhaps.

> 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.
I tend to think making the forms backend part suitable for
Syan's code, too, actually *improves* it because it makes us
think hard about how to define forms cleanly while also not
sacrificing the dynamic power you are asking for.

> 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_fields too lowlevel to
> produce a sane interface automatically.
My idea would be to have form_field_defs define what the types
of the fields are but not include any information on how to
display them. IOW, a dictionary of fields that can be
combined to make a form.

> > I have the feeling that once we factor out form_field_gui_defs
> > from form_fields we might find things clearer.
> How would you split this table? What would be left in form_field_defs?
Actually, I just now realize that form_fields links *towards*
form_defs. Do you think it worthwhile to use a linking table
lnk_field2form such that the field definitions can be reused
across forms ? It is more trouble in programming, though. As
it is now a, say, "drug_list" field has to be redefined for
every single form. Also, as it is now it makes sense to have
display_order and param in form_fields as they are specific to
a given form. Those should otherwise be moved into another table.

> > Eventually, clinical.form_data might need an fk_form_fields.
> Yes.
I added a FIXME such that we get reminded once we decide.

> > 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.
Oh, you mean while the queue is the *type* of transport
channel the url would be the target designation *within* that
channel. I missed that distinction. Of course, one could argue
that one could always set up fixed-target queues as needed which
would amount to the same thing.

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