[Top][All Lists]

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

[Gnumed-devel] Re: problem with UI/logic separation

From: Hilmar Berger
Subject: [Gnumed-devel] Re: problem with UI/logic separation
Date: Tue, 24 Feb 2004 16:41:24 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.4) Gecko/20030619 Netscape/7.1 (ax)

Karsten Hilbert schrieb:

Why is it undesirable to split into __init__ and
initiate_encounter ?  Because it would be desirable to not
require the programmers to think about whether they need to
call initiate_encounter() after getting a handle on a patient
chart object.
Due to the fact that we use lazy instantiation of the EMR
object (upon first access to it via the patient object) any
access can be the one needing to initialize an encounter.
Hence any access would need to be followed by
So you have a situation where GUI-level code calls non-Gui-level code which can fail and you don't want to communicate the error back to the calling GUI-level code but instead keep all error-handling logic in the non-GUI code. Still you want to have some GUI-interaction to resolve the error. That's what I call a lot of magic :). So we need some way to call GUI code from non-Gui code without returning to the calling GUI code first, right ? Does that work if the non-Gui code is in the same thread as the calling Gui-Code ? You could have a sleeping GUI-thread that waits for messages from non-GUI code to show some question and return the answer (via gmDispatcher). Or you could define a critical point in your Gui-Non-Gui interaction where __init__ is called and the presence of the encounter checked explicitely. Then the GUI could handle the error once for all.
Well, I don't know if this ideas make sense...


reply via email to

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