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

[Ian Haywood]

Karsten Hilbert wrote:
> > either that , or rearrange the backend a bit so the singleton idea
> > isn't mandatory.
>
> Relaxing gmCurrentPatient to not be a Singleton does not make
> sense. After all that's why it's called as it is. However, if
> you forego the comfort gmCurrentPatient offers and start
> dealing directly with cPerson you are free to have as many of
> them around as your machine affords.
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.
> Ian, I also think this is a more suitable place to decrease
> find_patient_ids granularity to. Return cPerson instances from
> find_patients(), not cDemographicObject ones. We would then
> enhance gmCurrentPatient to switch in cPerson instances as well
> as primary keys. Would you mind rethinking your patch along
> those lines ?
Certainly.

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.
(ideally we should have a match provider for this too)

> 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.
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.

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, .....)
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 
(but I agree it will never cover 100% of cases).
 We could get rid of display_order, and let the GUI use its own heuristics to 
decide field placement.

Ian



> Karsten

signature.asc
Description: OpenPGP digital signature