On Sat, Nov 19, 2005 at 02:03:27PM +0800, [EMAIL PROTECTED] 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. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
