Mindwrapper event handlers
This posting started out to be just a test to make sure I have set things up correctly, but since I have an active issue on my mind right now, I'll write a little about it now.
The Mindwrapper syntax is essentially declarative in nature. Although it is possible to include procedural style Python code in the
assemble()definitions, I have tried to discourage this practice (by making it mostly unnecessary). The user-developer will surely want to put procedural code someplace, though, so the trick is to keep it in well-designated locations. Since procedural code is executed in response to an event, such code may be considered an event handler. In the abstraction layer, this code is found primarily in the
backward()) method(s) of dependent cells. [Note: when I have time, go back and review what
forward()method acts as an event handler, where each event is a change in one of the observables to which the dependent cell is attached. In the abstraction layer there is just one type of event to be handled (the change event). Thus binding the handler to the event source is straightforward (and entirely transparent to the user-developer).
In the presentation layer, however, there are many different kinds of events. For some presenters, such as
mw.Field, the expected events (
EVT_KILL_FOCUS) are handled the same way in every instance. In these cases, binding events to their handlers is automatic and transparent. On the other hand, some presenters, such as
mw.Button, are designed to have custom commands associated with them. This might be called the controller role of a presenter. The user-developer must write the procedural code in a method and bind this code to the proper event (
EVT_BUTTON). The question is where is the best place to define this method (the event handler)?
One option would be to define a subclass of
on_command()method. Access to outside entities would have to be through a "global" attribute
self.app. A second option would be to define a named handler in the composite presenter where the button is added and use the "
command =" parameter of the
add()method. A third option would be to define the handler upstream, say in the enclosing frame, and again use the "
command =" parameter.
A fourth option has occurred to me, which is to define a separate class for the command itself, say with a
do()method. The class would be passed to the "
command =" parameter of the
mw.Buttonwould know to bind the
EVT_BUTTONevent to the
do()method of the instance. Potentially there are two advantages of such an implementation. One is that the command could be given an
undo()method as well. And the other is that the command could be used by other presenters, such as a menu item (not that a custom handler would not also be available to both button and menu item). At any rate, I have not implemented this last option, but it might warrant experimentation.