gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jim Busser
Subject: Re: [Gnumed-devel] Date parsing in Postgres/GNUmed
Date: Sun, 07 Aug 2011 09:24:07 -0700

On 2011-08-07, at 1:50 AM, Karsten Hilbert wrote:

> I understand the split-brain situation that you feel unhappy
> about. Let us dissect it:
> 
> - you enter 11/1/86
> - you dismiss the date suggestions
> - no date is attached to "Born" <--- in memory / logic / middleware
> - you hit save <--- and I see, painted, my raw input as read-only
> - GNUmed validates the field
> - "Born" does not have a date attached 
> - GNUmed looks at the string inside "Born" <--- which from user-view is 
> painted on the screen
> - GNUmed parses that string
> - it finds "1986-11-01" as the only match
> - it uses that match
> - it saves
> - it is done

Perhaps I did not (but now do) correctly understand what was going on… 
hopefully it is enough that you can maybe reply "correct".

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 in which case I would expect some kind of beep 
and pink-backgrounded field).

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.

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 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 (but failure to select it does not change anything).

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

-- Jim


reply via email to

[Prev in Thread] Current Thread [Next in Thread]