[Gnumed-devel] another try:

[syan tan]

regarding the editarea, I think it is like the old idea of template 
forms, or the old idea in latest clothes of XForms (see the xml XForms 
spec).
XForms is pretty feature heavy and seems mainly for html;  there is one 
free browser (which is disclaimed as a research browser)
called Xsmiles which claims to implement Xforms , and the rest aren't free.

I was thinking of a hybrid configuration file ( in xml at the moment; 
perhaps yaml might be better, but a python xml parser already exists) , 
that defines relationships
e.g. containment, many-to-one, one-to-many, many-to-many between tables 
in a schema ,

and using dbapi cursor.description to get the individual tables' fields 
and types. ( I didn't go further to suggest using pg_relate table 
because it's more vendor specific than dbapi ).

Then the same thing goes, define a type of widget and map it to a model 
element; e.g.
individual fields are textboxes,  checkboxes,  or spinners (for 
date/time  and numbers);
many-to-one  are comboboxes or phrasewheel with a "table.description" 
mapping where the description is a field on the  one-side
table which provides the selection list. 
one-to-many ui mapping  hasn't been done yet , but could consist of:

a) recursively contained editarea + list  
b) 2 panel tabbed pane with list on one pane, and editor of current 
selection or new item on other pane
c) list with button, where new pops up empty editarea dialog, and edit 
pops up editarea with selected list item.
or
d) if each of the table-relations on the many side is complex, one tab  
per item on the many side.
e) A list of a table-relation which has subtypes is also like a 
one-to-many , one-to-many  , where the first level is items divided by 
subtype, and
the second level is the items  of each subtype list.  The natural 
mapping for this application here is tabs of editarea-list combinations.


As before, a chain of many-to-one mappings is just a narrowing 
relationship , e.g. drug_class narrows generic_drug, narrows brand_drug 
, so that any
selection on any item along the chain, will update above and below that 
item by altering the selection list (  on the one side of a many-to-one 
then just one item, which will propogate down the one sides,  and on the 
many side, a subselection of items, that defaults to the first item and 
proprogates down as the one side of one-to-many to the next subselection ).



It sounds complicated at first, but I think it's doable .

here's the beginnings of a model definition that maps the relations of 
the current gmclinical.sql database. (There's a variation in vaccination 
because of its use of integer arrays as one-to-many references, which 
doesn't work on my postgres. )

a view definition can then follow. Possibly a action definiation later ( 
with validation rules?)

If  user interface definition by configuration with either xml or yaml 
files is possible, then communication could be the same as well, as well 
as data import/export transformations ( not sure if this pie-in-the-sky 
until it's attempted).
comments?






<model use_dbapi_cursor_description="true" default_primary_key="id">
<class table="clin_encounter">
        <ref table="_enum_encounter_type" field="id_type"/>
</class>        
        

<class table="clin_health_issue">
        <ext_ref field="id_patient"> patient </ext_ref>

        <list table="clin_episode" parent_field="id_health_issue"> 
                <list table="clin_root_item" parent_field="id_episode">
                        <ref table="clin_encounter" field="id_encounter"/>
                        <subtype table="clin_note"/>
                        <subtype table="clin_aux_note"/>
                        <subtype table="clin_history">
                                <ref table="_enum_hx_source" field="id_source"/>
                                <ref table="_enum_hx_type" field="id_type"/>
                        </subtype>
                        <subtype table="clin_physical"/>
                        <subtype table="vaccination">
                                <default_field field="fk_provider" value="1" 
type="int"/>
                                <default_field field="fk_patient" value="1" 
type="int"/>
                                <ref table="vaccine" field="fk_vaccine">
                                        <ref table="vacc_indication" 
ref_table="lnk_vaccine_indications" from_field="fk_vaccine" 
to_field="fk_indication" create="true"/>
                                        <ref table="vacc_route" 
field="id_vacc_route"/>
                                </ref>
                                
                                <ref table="vacc_appt" field="fk_vacc_appt">
                                        <ref table="vacc_indication" 
field="fk_indication"/>
                                        <ref table="vacc_regime"  
ref_table="lnk_regime_appt" from_field="fk_appt" to_field="fk_regime" 
create="true"/>
                                </ref>
                        </subtype>
                        <subtype table="allergy">
                                <ref table="_enum_allergy_type" 
field="id_type"/>
                        </subtype>
                        <subtype table="clin_diagnosis">
                                <list table="clin_diagnosis_extra" 
parent_field="id_clin_diagnosis">
                                        <ref table="enum_confidentiality_level" 
field="id_enum_confidentiality_level"/>
                                </list>
                        </subtype>
                </list>
        </list>
</class>
</model>