On Jun 6, 2004, at 6:07 PM, sjtan wrote:
- change to request / event notify / receive style of business
object invocation, instead of rpc style, as is currently.
- within the business object, there would be a request queue and a
consumer / dbapi calling thread that services the queue, and places
the results in a synchronized dictionary, then issue events on a
event dispatcher
IMHO this is the way to go although I apprecipate its very different
from what we have
unsynchronise business object request, response, and gui update using
event driven coding style in the client. Use client-side business
object proxies to do the waiting and response notification.
I would envision a middleware that's a bit more like PROLOG: a set of
rules, each with 4 elements
1 - the event that fires them (either GUI, backend via NOTIFY/LISTEN
or internal like "new_patient")
2 - the GUI-specific function which grabs data from the appropriate
widgets
3 - the SQL query, run in the background
4 - the GUI-specific function which unpacks the data and loads it
into widgets (which MUST be in the foreground thread)