Re: [Gnumed-devel] Two patches

[Ian Haywood]

Karsten Hilbert wrote:
> > Not really, they define the data types the form template wants, with
> > one display hint.
>
> Ah, OK, this seems to be a point of view I hadn't considered.
>
> I agree this is useful which is why I said it's worth
> exploring.
>
>
> > IMHO a interesting proportion of form GUIs can then be
> > auto-constructed, but I agree not all, some forms will need a "hand-written"
> > GUI form which then passes the data directly to the templating layer.
>
> I fear most of them will be that way but, hey, your additions
> don't limit that. Also there may be more and less smart form
> GUIs such that a form *can* be filled out even when there's
> no specially tailored GUI for it...
>
>
> > Some forms may not even have a GUI, one could imagine a nightly cron
> > job which prints out patient reminder letters and reports to payors and 
> > other third-parties overnight while no-ones using the printer.
>
> True enough.
>
>
> > > Strings, bools, lists and such don't do the job. Also, for
> > > quite some lists we won't know the list content until runtime.
> >
> > Indeed, what I'm aiming for is a rich set of high-level types,
> > which GUIs can display however they see fit.
>
> Well, it's not just *how* they see fit. Most of the smarts of
> an input field is in the supporting context code, eg. even if
> a GUI decides to represent "text" fields by STCs and string
> 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.
> Unless that's defined
> somewhere 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 ;-)

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

Sure, this means the forms are gnumed-specific [although the forms layer itself 
is not, and
could be ported to a Python app with a different business layer API fairly 
easily] but I'm not
sure what's wrong with that.

Ian

signature.asc
Description: OpenPGP digital signature