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

[Christian Heller]

Hi Karsten,

sorry for late reply; one week of ski-holiday :-)

> Specific situation:
>
> gmClinicalRecord.__init__() tries to make sure there is an
> active/ongoing encounter. If it finds one with an age between
> the soft time-to-live and the hard time-to-live it must ask
> the user whether to consider that one as still active or to
> proceed with creating a new encounter ...

I am not sure if I see a problem here. The "init" method initializes
an EHR and pops up a dialog if questions occure. The dialog returns
an answer code so that initialization can continue?

> What's the "best"/accepted way to deal with this: non-GUI code
> needs to make GUI functions run but has no good way of simply
> returning with an error so that the (GUI level) caller can
> take appropriate action ?

From what you write, I assume you have the following architecture:

GUI (View)
  |
  v
Non-GUI (Controller + Model)
  |
  v
DB

In which of these layers is your "main" method that starts the process?
It sounds like your GUI depends upon the Non-GUI layer.
How about this architecture:

GUI (View)
  ^
  |
Non-GUI (Controller + Model)
  |
  v
DB

Dependencies between layers should be unidirectional, if possible.
The startable "main" method would be in the "Non-GUI" layer.
If you want to be able to use graphical error/ log dialogs right from
the start, the "main" or "init" method would have to first initialize
the GUI stuff -- and possibly create an empty GNUmed GUI.
In a next step, an EHR could be opened by a user (read from DB).

It may also be useful to insert one more layer:

View
  ^
  |
Controller --> DB
  |
  v
Model

The "Controller" is the GNUmed process; the DB another process (system).
The Controller catches all GUI events and contains the logics and
algorithms to process them. If such an algorithm needs user interaction,
the Controller gives the command to create for example a dialog GUI,
waits for input and continues processing.
If needed, the Controller accesses the DB to fetch (remote) data from it.
The OO "Model" reflects the DB structure and serves as cache, that is
data retrieved from the DB are stored as objects of classes of the
Model layer.

> There are several options:
[...]

None of these, really. Better try to change the dependencies or
system structure to avoid these problems.

But may be I misunderstood your problem. Do my ideas make sense?

Christian

(For answers: Put me on CC:!)