Calling application methods from the wx frame class
I am getting started with wxPython and am working through every tutorial and example I can use. However, I got a little problem and it has to do with wx.App and wx.Frame and must contain certain methods. Almost every example I have seen is not much different from layouts / sizers and event handling, none of which is concerned with the design 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 to the method right in the frame class. This method can be used in several other parts of the application, so it makes sense to store it at the application class level.
How do I organize and name "generic" methods like these so that I don't clutter my frame classes.
UPDATE:
To clarify, the "folder list" was just an example, my actual method does a lot more work. I say that I have code that is not a frame. If I had this in my application class, what is the best way to name it and the event method in my frame.
I'm looking for real methods of organizing a project, not the basics of programming.
source to share
Your classes that inherit from the wxWidgets / wxPython datatypes do not need to implement any business logic. wxWidgets is a graphical library, so any subclasses of wxApp or wxFrame should remain focused on the graphical interface, which renders the interface and responds to user input.
Code that does something useful should be separated from wx as you can later use it in some kind of web or console application, in which case you don't want to create a wxApp object. You may also later decide to move some of the computations to separate the "work threads" while your GUI will be the "main thread" - responsive and repainted correctly during lengthy computations.
Last but not least, the classes that encapsulate your logic can grow over the life of projects. If they are mixed with your GUIs, they will grow faster, and finally, they will become so complex that you can hardly debug them ...
Separating them leads to clean code when you don't mix bugs in logic with bugs in GUI (update / layout / progress bar, etc.). This approach has another nice feature - the ability to divide work between GUI people and logical people who can do their job without constant conflicts.
source to share
As Mark said, you should create a new class that handles things like this.
Ideal code layout when using something like wxWidgets is a model view controller, where the wxFrame class only has the code needed to display the elements, and all logic and business rules are handled by another class that interacts with wxFrame. This way, you can change logic and business rules without changing your interface, and without changing (or swapping) the interface, without changing your logic and business rules.
source to share
I probably should have been a lot clearer from the start, but I found what I was looking for:
http://wiki.wxpython.org/ModelViewController/
Diving into the wxpython wiki I found some simple, concrete example MVC projects.
source to share