[Top][All Lists]

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

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

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Re: problem with UI/logic separation
Date: Mon, 23 Feb 2004 19:32:39 +0100
User-agent: Mutt/

>> 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?
Yes. But the EHR is a non-gui class. It doesn't know what GUI
is there and it also doesn't know how to ask a question using
the GUI that might be there (it currently does precisely
because of the above problem but I don't feel comfortable with

>>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?
In the Non-GUI.

> It sounds like your GUI depends upon the Non-GUI layer.
It uses it, so yes.

> Dependencies between layers should be unidirectional, if possible.
I am precisely asking for the case where this appears
to be impossible.

> The startable "main" method would be in the "Non-GUI" layer.
It is.

> 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.
So we do.

> In a next step, an EHR could be opened by a user (read from DB).
So we do.

> 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.
We are trying not to reinvent wxWidgets.

> None of these, really. Better try to change the dependencies or
> system structure to avoid these problems.
And what do I do before dying of old age ?

> But may be I misunderstood your problem. Do my ideas make sense?
I think you understood it, or maybe not quite. The ideas make
sense but are not practical for me AFAICT.

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]