[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] inter-module communication
From: |
Horst Herb |
Subject: |
Re: [Gnumed-devel] inter-module communication |
Date: |
Wed, 4 Sep 2002 17:55:47 +1000 |
User-agent: |
KMail/1.4.6 |
On Wed, 4 Sep 2002 01:44 am, Hilmar Berger wrote:
> If I get it right all module - module data transfer works through the
> backend and only signaling is handled by gmDispatcher ? This would imply
> that modules can access only backend objects and for every possible
> inter-module data transfer there has to exist at least one corresponding
> backend object. That is, after receiving the signal 'patient changed' I
> have to access the backend via 'personalia' service.
Almost. For data which is likely to be needed by multiple widgets (like a
person's name and address) the data should be accessed via an abstract cache
object.
Example: all widgets that change the "current patient", send a request to the
"CurrentPatient" cache object. The cache object updates itself, which
triggers a "update" message via dispatcher to all widgets that have
registered an interest in such event via dispatcher.
To go back to your question regarding "initial state": the initial state of a
widget is usually blank, or otherwise defined in the widgets constructor.
When constructed, a widget simply registers it's interest in certain data
with the dispatcher. On notification by dispatcher, it then either queries
the backend directly or an abstract cache object in order to get the data to
update itself.
> Sounds good to me, I just got the impression that we would like to supply
> the changed data via the parameters of the callback function itself (which
> would be possible with gmDispatcher). We will see if the suggested
> communication via the backend is to slow and build an lightweight
> transfer channel via gmDispatcher only if we really have to.
The data that could/should be transferred via dispatcher is the primary key of
the backend object to be queried, if applicable.
This would leave another avenue for the caching mechanism: a dictionary of
primary keys! The only problem involved her is reference countind, since
automatic garbage collection could not work for such mechanism and memory
would quickly fill up if we would not discard query results no longer in use.
Horst