Data access from multiple code modules

[simon.hibbs]

Lets say that I have an application consisting of 3 files. A main.py
file, gui.py and a data.py which handles persistent data storage.
Suppose data.py defines a class 'MyDB' which reads in data from a
database, and main.py creates an instance of this object. How does code
in gui.py access this object? Here's simplified pseudocode:

MAIN.PY
import gui, data
DataObject = data.MyDB(blah)

How do I write code in gui.py that can access DataObject? Is this
entirely the wrong way to approach this sort of problem?

Actualy the problem is more complex because the GUI consists of a main
GUI form, and panels defined as seperate objects in seperate files.
Various panels will contain controlls for manipulating data in the
DataObject, or wherever data storage end up.
Best regards,

Simon Hibbs
(who strugles to get his head round this OOP stuff sometimes).

[Jeremy Jones]

si*********@gmail.com wrote:

Lets say that I have an application consisting of 3 files. A main.py
file, gui.py and a data.py which handles persistent data storage.
Suppose data.py defines a class 'MyDB' which reads in data from a
database, and main.py creates an instance of this object. How does code
in gui.py access this object? Here's simplified pseudocode:

MAIN.PY
import gui, data
DataObject = data.MyDB(blah)

How do I write code in gui.py that can access DataObject? Is this
entirely the wrong way to approach this sort of problem?

Actualy the problem is more complex because the GUI consists of a main
GUI form, and panels defined as seperate objects in seperate files.
Various panels will contain controlls for manipulating data in the
DataObject, or wherever data storage end up.

What does main.py do? Are you creating an instance of the gui thingy?
If so, you could just pass DataObject into your gui thingy either into
the constructor or to a setter once you create an instance of it. If
the gui needs any database stuff at instantiation time, you probably
need to pass it into the constructor. However, a main.py, gui.py, and
db.py smells a little like your standard MVC, in which case, you would
get your controller to pass in the data pieces as the GUI needs them.

- Jeremy M. Jones

[Bruno Desthuilliers]

si*********@gmail.com wrote:

Lets say that I have an application consisting of 3 files. A main.py
file, gui.py and a data.py which handles persistent data storage.
Suppose data.py defines a class 'MyDB' which reads in data from a
database, and main.py creates an instance of this object. How does code
in gui.py access this object?

Obviously, you need to pass whatever relevant to this code...

Here's simplified pseudocode:

MAIN.PY
import gui, data
DataObject = data.MyDB(blah)

How do I write code in gui.py that can access DataObject?

Passing DataObject to code in guy.py seems like a very straightforward
solution...

Is this
entirely the wrong way to approach this sort of problem?

Actualy the problem is more complex because the GUI consists of a main
GUI form, and panels defined as seperate objects in seperate files.
Various panels will contain controlls for manipulating data in the
DataObject, or wherever data storage end up.

Hmmm... Hard to tell without seeing the code (and I've not done GUI
programmer for a long time), but putting application logic in the GUI is
usually a bad idea IME. Better to put the application logic in a
separate controler (that has a reference to the model -here your
DataObject), and have the GUI part call on the controler.

>
Best regards,

Simon Hibbs
(who strugles to get his head round this OOP stuff sometimes).

Well, actually one can do MVC without OO. It's more a matter of
separating concerns. Now I agree that it's not always obvious to know
for sure which part should be responsible for what...

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[simon.hibbs]

Jeremy Jones wrote:

What does main.py do? Are you creating an instance of the gui thingy?
If so, you could just pass DataObject into your gui thingy either into
the constructor or to a setter once you create an instance of it.

It's a wxPython app. I created the GUI initialy using wxGlade which
gave me a small myapp.py script, a file containing the main application
frame (containing a listbook controll) and several files containing
panel classes. Each panel class contains controlls for performing
various operations on the data set (adding records, deleting them,
running various transformations). I can't say I understand how it all
works at a deep level, although I've been hacking it about quite
successfuly so far.

Presumably if I pass DataObject through to the Frame object, and from
there through to the Panel objects then presumably this will solve the
probelm? I guess it would be passed by reference so all the panels
would be working on the same data object?

Doh! How simple. Why didn't I think of that? I'm too used to procedural
scripts where you'd just put everything in a global data structure. I
know this is bad, but it's hard to get out of that mentality.

Many thanks,

Simon Hibbs

P.S. Regular reader of your blog on Oreillynet.

[Jeremy Jones]

si*********@gmail.com wrote:

<snip>

Doh! How simple. Why didn't I think of that? I'm too used to procedural
scripts where you'd just put everything in a global data structure. I
know this is bad, but it's hard to get out of that mentality.

Sounds like you got it. Just pass it on down as needed.

- jmj

[Bruno Desthuilliers]

si*********@gmail.com wrote:

Jeremy Jones wrote:

>>What does main.py do? Are you creating an instance of the gui thingy?
If so, you could just pass DataObject into your gui thingy either into
the constructor or to a setter once you create an instance of it.

It's a wxPython app. I created the GUI initialy using wxGlade which
gave me a small myapp.py script, a file containing the main application
frame (containing a listbook controll) and several files containing
panel classes. Each panel class contains controlls for performing
various operations on the data set (adding records, deleting them,
running various transformations).

Do you mean the code effectively doing these operations is in the gui ?
If yes, it would be better to factor it out IMHO.

I can't say I understand how it all
works at a deep level,
although I've been hacking it about quite
successfuly so far.

Presumably if I pass DataObject through to the Frame object, and from
there through to the Panel objects then presumably this will solve the
probelm?

Presumably !-)

I guess it would be passed by reference so all the panels
would be working on the same data object?

Python doesn't really have a "pass by value" semantic, since "variables"
are really just names bound to (ie : refering to) objects. So when it
comes to arguments passing, the argument *name* is local to the function
(rebinding the name won't affect the binding in the caller's namespace),
but what's bound to the name is really a reference to the object (so
mutating the object will effectively affect it).

Doh! How simple. Why didn't I think of that? I'm too used to procedural
scripts where you'd just put everything in a global data structure. I
know this is bad,

Well, depends on the size of the script. But it sure doesn't scale !-)

And FWIW, even with procedural, it's possible (and usually better) to
pass arguments around instead of having a big global datastructure.
Classes are handy when many functions needs to share state (work on a
same dataset), but there's no way to have one call the other and pass it
the dataset.

but it's hard to get out of that mentality.

Seems you're on the right way !-)

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[simon.hibbs]

Bruno Desthuilliers wrote:

Do you mean the code effectively doing these operations is in the gui ?
If yes, it would be better to factor it out IMHO.

The GUI has to be able to acces the data object, otherwise how does the
user affect any changes to the application data? If I modify a value in
a text box and hit Apply, that change must be propagated to the data
model somehow. Similarly, the GUI must access the data to display it.

Actualy this has nothing to do with code modules. The problem is is you
have one object that contains your data, and your app consists of
several objects that need to interact with it, how do these other
objects access it? I'm fairly new to OOP and Python so I don't know
it's scoping rules very well.

Simple example:

One way would be to use the database as the point of contact for all
the object. Every object that wants to read or write to the database
instantiates an object to interact with the database and performs
whatever actions it needs. That way each top-level objecyt will contain
it's own instanced database IO object. Their only point of contact with
each other is the database itself. This could lead to synchronisation
problems though.

Another way would be to create one instance of the database IO object
and then pass it as a parameter to the other application objects when
they are created. The point of contact between the application objects
would be the single database IO object, with the database behind it.
This seems to me to be the superior approach.

Are there any other architectural options that anyone could suggest?

Simon Hibbs

[Bruno Desthuilliers]

si*********@gmail.com wrote:

Bruno Desthuilliers wrote:

>>Do you mean the code effectively doing these operations is in the gui ?
If yes, it would be better to factor it out IMHO.

The GUI has to be able to acces the data object, otherwise how does the
user affect any changes to the application data? If I modify a value in
a text box and hit Apply, that change must be propagated to the data
model somehow.

Yes, obviously. But that's not what I said. My advice is to seperate the
GUI code (view) from the code operating on data (controler), so
operations are independant from the GUI code itself. Of course the view
needs to call back on the controler(s), and the controler(s) need to
have a refence to the model.

Similarly, the GUI must access the data to display it.

Yes, obviously. But here again, it may be better to just have the GUI
call back on the controler(s) to get needed data.

Actualy this has nothing to do with code modules. The problem is is you
have one object that contains your data, and your app consists of
several objects that need to interact with it, how do these other
objects access it?

I'm fairly new to OOP and Python so I don't know
it's scoping rules very well.

Simple example:

One way would be to use the database as the point of contact for all
the object. Every object that wants to read or write to the database
instantiates an object to interact with the database and performs
whatever actions it needs.

If by "any object", you mean "any GUI widget", then this his how
languages like VB and Delphi (and other "DB->GUI pipeline" tools) work,
and it's an approach that is known to have some drawbacks.

That way each top-level objecyt will contain
it's own instanced database IO object. Their only point of contact with
each other is the database itself. This could lead to synchronisation
problems though.

Another way would be to create one instance of the database IO object
and then pass it as a parameter to the other application objects when
they are created. The point of contact between the application objects
would be the single database IO object, with the database behind it.
This seems to me to be the superior approach.

I don't know enough of your "database IO object" and "other application
objects" is a too vague definition, so I can't really comment on this,
but it seems like we are in the same situation as above.

Are there any other architectural options that anyone could suggest?

Separating operations on data (model/controler) from GUI code (view).
The controler(s) have a reference on the model. The views have a
reference on the controler(s), and call on the controller to get data to
display or act on data.

My 2 cents
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[simon.hibbs]

Bruno Desthuilliers wrote:

Separating operations on data (model/controler) from GUI code (view).
The controler(s) have a reference on the model. The views have a
reference on the controler(s), and call on the controller to get data to
display or act on data.

So I instantiate a Model object that handles all IO to the database.
Next I instantiate a Controller object, passing it a reference to the
Data/IO model object. Next I instantiate the display panel objects for
the GUI, passing them references to the Controller object.

The Controller object contains the logic for all the transformations I
want to perform on the data.

Simon Hibbs

[Fredrik Lundh]

si*********@gmail.com wrote:

So I instantiate a Model object that handles all IO to the database.
Next I instantiate a Controller object, passing it a reference to the
Data/IO model object. Next I instantiate the display panel objects for
the GUI, passing them references to the Controller object.

The Controller object contains the logic for all the transformations I
want to perform on the data.

sounds reasonable.

note that for simple applications, you can put the controller logic in the Model
object, and let the UI call the relevant methods directly. however, putting con-
troller logic in the UI code is almost never a good idea.

or in other words, if "do_update" is an UI callback that's called when the user
clicks "Update" in your UI, doing

def do_update(self):
self.controller.update()

or

def do_update(self):
self.model.update()

is perfectly okay, but

def do_update(self):
sum = 0
for record in self.model.select(...):
sum = some operation
self.model.update(...)

isn't a good idea.

</F>

[Bruno Desthuilliers]

si*********@gmail.com wrote:

Bruno Desthuilliers wrote:

>>Separating operations on data (model/controler) from GUI code (view).
The controler(s) have a reference on the model. The views have a
reference on the controler(s), and call on the controller to get data to
display or act on data.

So I instantiate a Model object that handles all IO to the database.

FWIW, you may want to have a look at SQLAlchemy here.

Next I instantiate a Controller object, passing it a reference to the
Data/IO model object.

Yes. Note that you can have multiple controllers...

Next I instantiate the display panel objects for
the GUI, passing them references to the Controller object.

Yeps. Or the other way round - the gui instanciation can be the resp. of
the controller (which then passes itself to gui), but then this more
strongly ties the controller to a specific GUI and/or can force you into
a more strict controller <-view protocol to abstract out any GUI
Toolkit specificities...

Now only having done web apps the past years, I may be a bit biased, so
you'd better look for other writings about the MVC stuff. Just note that
what was originaly the main bulk of the "controler" part (ie mapping
mouse and keyboard events to appropriate callbacks) is now mostly done
by the GUI Toolkit itself.

The Controller object contains the logic for all the transformations I
want to perform on the data.

Yes. And for data querying as well.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"