Re: [Gnumed-devel] Re: web frontend/patient singleton

[Karsten Hilbert]

> However you can't have multiple logged-in *users*, this is nothing to do 
> with singletons, it's a rule of Gnumed/pycommon/gmPG.py Hacking it to allow
> multiple users is certainly possible, but it all gets very complicated.
> Much better to launch another process for each new user.
I agree.

> However I would like find_patients to to wrap find_identities, because
> we may want to use your search algorithm to find people who are not 
> patients
Oh, the search doesn't care at all what type of identity it
finds. Even now it just returned IDs no matter whether they
were patients or not (eg did not have any clinical data
associated with them). The confusion stems, perhaps, from
gmPatient.py having been unaptly named. It should have been
gmPerson.py. That is the reason why gmPatient.gmPerson is
named like that: it is a person, not a patient. It only
becomes a patient when you start requesting clinical data from
it (eg. after the first request of get_clinical_record()).

> (ideally we should have a match provider for this too)
I previously dismissed that idea as likely being too slow but
that may be a misconception.

> You can do this, but to my mind, this is turning form_field_defs into the 
> "field type"
> table, and whichever table you put display_order and param, becomes the new 
> "fields" table.
True enough. Let's leave it as is for the time being.

> Can I propose a concept of a "compound field type", that is a field with 
> named sub-elements.
> The form template, instead of python snippets, accesses them via a slash, so 
> patient/firstnames,
> user/address, drug/1/dosage, etc.
> Of course, in the reference client these are constructed directly from 
> business objects, as python dictionaries,
> but other clients can provide them however they please. This doesn't make it 
> any harder for them -- they would still need to
> provide this information as separate fields (patient_name, user_address, 
> .....)
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.

> (but I agree it will never cover 100% of cases).
Oh, never mind.

> We could get rid of display_order, and let the GUI use its own heuristics to 
> decide field placement.
Just leave it as is for now.

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