|
When you look at the GDBI classes,
you will notice that many functions don't have return a value.
So how do you get the Connection object after calling
Session::get_connection(), for example? You hook up a
function onto the Session::connection_opened signal. This
function then gets called whenever a connection is established and is
given the connection index as an argument, so you can access it via
the array returned by Session::connections().
Why is this all this complicated? Why not the straight, simple way and
have Session::get_connection() just return the
newly opened connection? Well, setting things up the way described
above has some (maybe not obvious) big benefits.
The function (get_connection() in the example) may return
immediatly and defer the work of actually opening a connection to
some queue or another thread, which then emits the signal.
This is a (quite elegant, I think) way to write non-blocking GUIs.
It also features the Document/View design pattern:
All GDBI objects are documents,
on which an arbitrary number of views can be generated. Since all views
that need to know when a connection is opened (for visualizing it), are
connected to the connection_opened signal, document changes are
reflected in all views without special coding.
| 
