Splitting MainWindow Class over several modules.

[Iain King]

Until recently almost all my python programs were held 1 file for 1
program. This had grown unwieldy for one of my projects, so i decided
to refactor it, and ended up with something like this:

---

import wx

import options
import gui
import scf

class MainWindow(wx.Frame):
def __init__(self):
self.title = "SFtools v%s" % VERSION
wx.Frame.__init__(self, None, wx.ID_ANY, self.title, size=(800,600))
self.SetMinSize((800,600))

readOptions = options.readOptions
writeOptions = options.writeOptions

createBindings = gui.createBindings
createControls = gui.createControls
createMenus = gui.createMenus
reportError = gui.reportError

loadSCF = scf.loadSCF
onOpen = scf.onOpen
reloadSCF = scf.reloadSCF
setMenuMode = scf.setMenuMode
unloadSCF = scf.unloadSCF

---

Now, this works fine. I like how it reads and that everything being
imported can be clearly seen. I have this funny feeling though, that
this isn't the standard way of doing this. What is? And is there
anything about doing it this way which could be detrimental?

Iain

[Mike Driscoll]

On Apr 16, 10:47 am, Iain King <[e-mail]:

Until recently almost all my python programs were held 1 file for 1
program. This had grown unwieldy for one of my projects, so i decided
to refactor it, and ended up with something like this:

---

import wx

import options
import gui
import scf

class MainWindow(wx.Frame):
def __init__(self):
self.title = "SFtools v%s" % VERSION
wx.Frame.__init__(self, None, wx.ID_ANY, self.title, size=(800,600))
self.SetMinSize((800,600))

readOptions = options.readOptions
writeOptions = options.writeOptions

createBindings = gui.createBindings
createControls = gui.createControls
createMenus = gui.createMenus
reportError = gui.reportError

loadSCF = scf.loadSCF
onOpen = scf.onOpen
reloadSCF = scf.reloadSCF
setMenuMode = scf.setMenuMode
unloadSCF = scf.unloadSCF

---

Now, this works fine. I like how it reads and that everything being
imported can be clearly seen. I have this funny feeling though, that
this isn't the standard way of doing this. What is? And is there
anything about doing it this way which could be detrimental?

Iain

I don't think there's anything wrong with it. The main thing to
remember is to try to keep the interface and the logic separate. I
have a fairly complex program with lots of tabs and sub tabs. So I
stuck each of the tab's display code in a separate file and imported
them into my main program.

One good place to learn from would be the wxPython demo. See how Dunn
et al did it with that. Or check out Editra's source. I know there's a
few wxPython-istas that love XRC for the GUI layout stuff, so that's
an option too. I don't use it myself as I couldn't figure out how to
implement some of the widgets with it.

Mike

[Ryan Ginstrom]

On Behalf Of Mike Driscoll

I don't think there's anything wrong with it. The main thing
to remember is to try to keep the interface and the logic
separate. I have a fairly complex program with lots of tabs
and sub tabs. So I stuck each of the tab's display code in a
separate file and imported them into my main program.

There are also several signaling techniques that make it easy to separate
the GUI logic from the message-processing logic. Or you could simply have a
controller class that instantiates the GUI class and registers itself as the
message listener.

Regards,
Ryan Ginstrom