gnumed-devel
[Top][All Lists]
Advanced

[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




reply via email to

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