I’m starting out with wxPython and have been working my way through every tutorial and example I can get my hands on. I’ve run into a slight problem, however, and it has to do with the wx.App versus the wx.Frame and which should contain specific methods. Just about every example I’ve seen don’t go much beyond layouts/sizers and event handling, none really tackle project organization of a wxPython project.
For example, I have a method that gets a list of folders. The way most examples would deal with this would be to stick the method right in the frame class. This method has the potential to be used in several other parts of the application, so it would make more sense to store it at the application class level.
How should I organize and call ‘universal’ methods like these so that I don’t clutter up my frame classes.
UPDATE:
To clarify, the ‘list of folders’ was just an example, my actual method does a lot more work. What I’m saying is I have code that isn’t Frame-specific. If I had this in the application class, what is the best way to call it from and event method in my frame.
I’m looking for actual project organization techniques, not programming fundamentals.
Your classes that inherit from wxWidgets/wxPython data types should not implement any business logic. wxWidgets is a GUI library, so any subclasses of wxApp or wxFrame should remain focused on GUI, that is on displaying the interface and being responsive to user actions.
The code that does something useful should be separated from wx, as you can decide later to use it in some web or console application and you don’t want to create wxApp object in such case. You can also decide later on to move some computations to separate ‘worker threads’, while your GUI will be the ‘main thread’ – responsive, and repainted properly during long lasting computations.
Last but not least – the classes that encapsulate your logic might tend to grow during projects lifetime. If they’re mixed with your GUI classes they will grow faster, and finally they become so complex that you’re almost unable to debug them…
While having them separated leads to clean code when you don’t mix bugs in logic with bugs in GUI (refreshing/layout/progress bar etc.). Such approach has another nice feature – ability to split work among GUI-people and logic-people, which can do their work without constant conflicts.