[Top][All Lists]

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

Re: [Gnumed-devel] popups saving data (was: gmDermTool)

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] popups saving data (was: gmDermTool)
Date: Sun, 20 Nov 2005 01:36:09 +0100
User-agent: Mutt/1.5.9i

On Sat, Nov 19, 2005 at 02:03:27PM +0800, address@hidden wrote:

> What about when a user is re-editing an existing clinical item in the SOAP 
> box?
> You can't escape the fact that the calling SOAP widget needs to pass in
> stuff when it instantiates the popup, and, of itself, I can't see why this is 
> a
> problem.
Neither do I. It's a quite reasonable demand of the API of
the popup to be able to accept pre-set data.

> Can I have a another go at implementing this which doesn't involve classes
> like SOAPCtrl (which I agree should have nothing to do with this stuff)
Sure, why not.

I assume you want to retry writing a non-modal solution.
Basically, what we'd want is a widget that can optionally
accept some data and allows editing that. It would need to
be able to either save it's data into the backend or return
the edited data to a caller - which doesn't mean the caller
needs to call the widget modally - it just needs to pass in
a return pipe function or negotiate some other sort of
callback. This somewhat depends on the availability of the
corresponding episode, too.

One problem that comes to mind right away - if the widget is
called non-modally and passes back data to the caller (say
the progress note widget) we would need to keep track of
*where* the widget was invoked such that we can insert the
summary string ...  We could, however, also agree to not
store the summary right *inside* the narrative that's
generated by the user but rather add it as another
clin_narrative row. However, that's not what we really want.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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