Re: [Gnumed-devel] Date parsing in Postgres/GNUmed

[Karsten Hilbert]

On Sun, Aug 07, 2011 at 09:24:07AM -0700, Jim Busser wrote:

> What I had been assuming was that the "Born" area in the
> Demographics plugin and likewise the input area in the
> patient creation widget were "raw" fields in that was was in
> there was going to be pushed into the back end (provided
> only that it did not fail validation

This wouldn't be possible since the backend stores a
timestamp object while the frontend can only have the user
enter a string. If we stored the string in the backend we
could not (among many other things) do DOB-based
calculations in the backend.

> in which case I would expect some kind of beep and
> pink-backgrounded field).

Which indeed happens, except that the field *did* validate
(albeit differently from what the user expected).

> What I had further assumed was that the phrasewheel
> offered suggestions which, if selected (meaning if the user
> additionally hit "enter"), this would conveniently replace
> the original raw input with alternative raw input which had
> the desired appearance and format.

Over and above that - which is correct - it also attaches
data to the phrasewheel, namely the data corresponding to
the string that was selected from the list.

How else would we conveniently allow the user to select
strings she recognizes while the backend wants, say, primary
keys to be put into integer fields as foreign keys ?

> What I gather now, however, is that the edit area is not
> in fact a representation of a "save area" but more like a
> pass-through which causes/allows the phrasewheel to
> determine those values which it knows about and which would
> be valid, and:
> 
> - in the case where only one match was found – and this
> is important: whether or not the user selected it – it is
> *this* value that would be passed into the back end;

If it wasn't for this there would be little use applying a
phrasewheel. That's the precise purpose: Offer to the user
convenient strings to select from which actually mean
something else.

The shortcoming of what a selected string means has been
greatly mitigated by

a) in the case of timestamps: tooltips with a verbose
   rendering of the input

b) dropdown list labels which can be more verbose than
   what is eventually shown in the field as field label

> if the
> user *does* select the value from the phrasewheel, they gain
> the additional brief benefit of seeing that reflected in the
> edit area next to Born

indeed

> (but failure to select it does not change anything).

Indeed. Most prominently because they may simply have
mis-typed and want to correct what they typed there rather
than select from among the choices offered.

> - in the case where multiple potential valid
> representations were determined by the phrasewheel logic,
> then whichever one would have been selected (with the
> "enter" key then pressed) would be taken as the
> representation to be saved into the back end.

No. It would be used as the *label* or *selector* on the
actual data (say, a PK integer or a timestamp) being saved
into the backend.

> If the user
> would escape out of the phrasewheel and saved without it
> being clear which match had been accepted, I am not sure
> whether GNUmed (seeing no other action) would have assumed
> the first in the list of matches.

It much depends on the actual phrasewheel / configuration
thereof.

Timestamp phrasewheels will try to turn the string into a
timestamp when losing focus or when asked to do so (or when
generating the dropdown list of suggestions, of course).

> But maybe it is now
> obsoleted if in GNUmed 1.x there will be no save absent
> something being selected in the list of possibilities.

This will most definitely lead to complaints about the
following behaviour:

- user types 27.12.1951
- user tabs into next field ignoring
  dropdown list which shows just one match
- user presses save
- GNUmed complains about missing timestamp
- user sees pink timestamp field
- timestamp field shows "27.12.1951"
- user tabs into timestamp field
- dropdown list showing just one match is shown
  again from which the user must select the
  single match

Is that the desired behaviour ?

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346