Re: Data access from multiple code modules
[EMAIL PROTECTED] 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 '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
Re: Data access from multiple code modules
[EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Data access from multiple code modules
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Data access from multiple code modules
[EMAIL PROTECTED] 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 '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
Re: Data access from multiple code modules
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Data access from multiple code modules
[EMAIL PROTECTED] 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 '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
Re: Data access from multiple code modules
[EMAIL PROTECTED] wrote: > 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Data access from multiple code modules
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Data access from multiple code modules
[EMAIL PROTECTED] 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 '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
Re: Data access from multiple code modules
[EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Data access from multiple code modules
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). -- http://mail.python.org/mailman/listinfo/python-list
