Re: [Gnumed-devel] test-area/sjtan

[Karsten Hilbert]

> > Someone with good GUI skills needs to find out how we can
> > still make sure we achieve the good visual design put forth by
> > Richard. I'm sure it can be done, but needs work.
> GTK styles should achieve much of this, I will commit the "Terry style" to 
> CVS soon.
OK, good. I still suspect someone needs to fine-comb the code
at some point to put a few "spacer" sizers here and there.
Richard will probably not fail to tell us when things have
gotten to that point.

> I was thinking a single object might have several match providers
> (gmTmpPerson would have ones for name, street, postcode, etc.)
Ah ! Of course, that makes sense.

> each a single function that takes the search string, plus any search context
> parameters.
That would mean moving from per-object method API for the match
provider to a functionality-API. Fine by me but we'd loose
some things such as setWordSeparators, EnableLearning etc.
When the API between phrase wheel and match provider is
reduced to passing in the name of the "getMatches()" method
how do you propose to handle auto-learning new phrases/recording
of changing scores on used phrases ?

> lambda expressions provide the context, so a function accepting a single 
> parameter is provided to the 
> phrase wheel for matching.
How would we employ lambda form methods ? I fail to understand
the need.

Also consider this complex example (which, however, does not
render invalid your proposal as one can still provide
cMatchProvider descendants): The user typed in a zip code. The
demographic widget deduces known matching street names via
v_zip2data. The user moves to the street input field which now
has a self-learning fixed-list (the v_zip2data streets) match
provider. However, the user types another street name not yet
known to the system to be correlated with that zip code. Upon
running out of matches in the fixed list derived from
v_zip2data and the user merrily typing away more letters the
phrase wheel would need to switch to an SQL match provider
hooked up to the general street table regardless of associated
zip code (since that street may well have been recorded before
under another zip code). Upon "confirmation" of the entered
data the system would associate the street with the zip code
(such that it would appear in v_zip2data next time around).
Table-wise this is entirely possible. I think on the phrase
wheel side this is only solvable with a dedicated match
provider (likely even a dedicated phrase wheel child similar to
the dedicated gmDateInput one). Again, this does not preclude
use of the function-hook API in those cases that warrant that.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346