The event-driven nature of a wxPython program has several implications for designing and coding. Since there is no longer an assumption about when events happen, the programmer cedes much of the control of the program to the user. Most of the code in your wxPython program is executed as the direct or indirect result of an action taken by the user or the system. For example, saving work in your program happens after the user selects a menu item, presses a toolbar button, or invokes a special key combination. Any of these events can trigger a handler which saves the user's work.
Another consequence of an event-driven architecture is that the architecture is often somewhat spread out. The code that is called in response to an event is usually not defined by the widget that triggered the event. Or to clarify, there's nothing in the nature of the binding between an event and its handler that requires them to have any relationship at all. For instance, the code called in response to a button click doesn't have to be part of the definition of the button, but can be in the button's enclosing frame, or any other location. When combined with a solid object-oriented design, this architecture can lead to loosely coupled, highly reusable code. You'll find that the flexible nature of Python makes it particularly easy to reuse common event handlers and structures between different wxPython applications. On the other hand, the uncoupled nature of an event-driven program can make it difficult to follow and maintain. When an event click happens in a button tied to a binder listed in the frame code, and the event invokes a method in a model class, it can be difficult to track it down. (To some extent, this issue is true of all object-oriented programming). In chapter 5, we will discuss code structuring guidelines for event-driven programs.
Was this article helpful?