gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] SOAP2.py questions from Richard


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] SOAP2.py questions from Richard
Date: Tue, 9 Nov 2004 23:04:36 +0100
User-agent: Mutt/1.3.22.1i

> > > But it does not work on wxPython 2.4. Unless we don't want a
> > > SOAP control in 0.1 this will not help us.
> Works fine for me, I'm still on 2.4
My fault. Upgraded from 2.4.0.6 to 2.4.2.4 and it worked.

> > Carlos has already
> > started to use it in writing a SOAP entry plugin for
> > HorstSpace.
> Excellent, but please don't pointlessly duplicate this work.
We'd be boneheaded if we did :-)

> > One thing I am wondering about is: How are we intended to deal
> > with data having been typed into a functional popup ?

> - parseable string, when we commit the SOAP, we parse
>   the text and do the database commits.
>   We can mark the text not-editable to prevent the user
>   messing it up. IMHO, with care, we can make strings parseable and readable.
works but IMO ugly

>       - use the string as a key to a cache dictionary of "hidden" objects. 
> This exists in vestigal form already.
Ah, sounds fairly OK to me ! Dict key collision would be a
concern. However, if two identical user-visible strings in one
and the same clinical note are supposed to mean something
different I think there is something wrong in the first place,
eg.

P: vacc, vacc

where the first "vacc" stands for "Td booster..." and the
second one for "1st HepAB shot" sounds quite bogus to me. The
user really should write

P: Td booster, HepAB #1

which would indeed give unique keys for the data behind the
strings collected by the vaccination popups.

So I guess we could work with that approach.

>       - wxStyledTextControl markers, which can be invisible, again as keys to 
> a cache dictionary.
With proper care we might be OK with just the strings. It's
not like we need to re-establish the connections later on,
right ?

> > # - this should not be a physical replacement for the edit
> > #   area, just a logical one where people want to use it !
> > #   IOW we will keep gmEditArea around as it IS a good design !
> I hope SOAP2 to be a complete superset of cEditArea functionality,
Superset is fine. Also, who doesn't want to use the edit area
in her coding shall not have to. However, I know I will keep
using it for now. It won't go away.

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




reply via email to

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