About the bus driver

lunes octubre 03, 2005 | Event bus | Permalink | Comentarios [4]

Spot the difference! What's the difference between these two figures? Which one do you think is the correct one? Which one do you prefer? Well, if we try to follow the Model-View-Controller paradigm, then: Controller: This responds to events, typically user actions, and invokes changes on the model (but *not* the view). (read more) So it seems that the second one is the correct one. It's the model that notifies the view about any change, and not the controller handling the view directly. (Of course that's the way things are done in Swing, so that approach is possibly more intuitive than the previous one, right?). So I propose being the model that pushes events into the bus whenever it is changed. The model should drive the bus. Actuators will then receive these changes and update the views accordingly. The flow of events would then be as follows: 1. Macro-components generate events, that travel the event bus using topics. 2. Controllers receive and coordinate these events, and modify the model accordingly. 3. The model fires events when changed, and these travel through the bus using (one or more?) topics. 4. The actuators are updated of changes and update the view accordingly. Opinions on this? What do you think? Since I'm afraid this is getting too academic let's see things by example. Opening files Let's assume the user wants to open a file. 1. The user selects "File/Open" in the menu (or in a toolbar) and an ActionEvent is generated from the menubar (toolbar) through the "menubar.events" or "toolbar.events" topics in the bus. 2. A controller is connected to both the "menubar.events" and "toolbar.events" topics and asynchronously reads the file and creates a javax.swing.text.Document for the file. 3. The controller updates the model inserting this javax.swing.text.Document in the model (possibly in the Swing thread). Once the model is updated it generates a DocumentOpenedEvent event through the "model.documents" topic in the bus. 4. There're different actuators listening on this "model.documents". The "MenubarActuator" will insert an entry in the "Recently opened" menu. The "EditorActuator" will open a new editor tab and include the new javax.swing.text.Document in an EditorPane. The "StatusBarActuator" will update the message in the status bar indicating that the file was opened. Note: if there's an IOException in step 2 above then steps 3 and 4 are not executed, but instead: 3. The controller updates the model inserting an Exception in the model's "errors" list. Once the model is updated the model itself generates a "ApplicationErrorEvent" through the "application.errors" topic in the bus. 4. There're different actuators listening on this "application.errors" topic. The StatusBarActuator, for instance, will show a red label with the error. Note there's no veto here: the controller detects the error and generates an event. Another example: closing the application 1. The user selects "File/Exit" in the menu (or clicks on the close window button in the window) and an ActionEvent is generated from the menubar (or a WindowEvent is generated). These events travel through the "menubar.events" or the "window.events" topics in the bus. 2. A controller is connected to both the "menubar.events" and "window.events" topics in the bus. The controller checks the model to see if all files are closed. If not then it will ask the user (in the event thread) if he wants to quit without closing. If the user selects "YES" then the controller updates the model indicating that the application has to be closed. If the user selects "NO" then the controller does nothing. 3. If the application has to be closed then the model fires an "ApplicationQuit" event through the "application.control" topic. 4. The "ApplicationActuator" releases all resources used by the views, closes and disposes all windows. Just one more example before continuing... Another example: saving Let's assume the user wants to save a file. 1. The user selects "File/Save" in the menu (or clicks the save button in the toolbar). An ActionEvent is generated from the menubar (or an ActionEvent is generated in the toolbar). These events travel through the "menubar.events" or the "toolbar.events" topics in the bus. li>2. A controller is connected to both the "menubar.events" and "toolbar.events" topics in the bus. The controller asynchronously saves the document (contained in a javax.swing.text.Document in the model). And then updates the model indicating that the document is saved. 3. When the document in the model is saved an "DocumentSavedEvent" is sent through the "model.documents" topic. 4. There're different actuators listening on this "model.documents" topic. The "MenubarActuator" will disable the save menu (because the document is saved). The "StatusBarActuator" will set a message indicating that the document was saved. What about errors? If there's an error saving the document in step 2 then the model won't be updated and steps 3 and 4 above will not be executed. The behaviour could be similar to the one when opening the file above. Vetoing and threading Note that in the examples above there's no need to veto events: it's controllers who are responsible for handling errors and unsaved situations, so all the hassle about handling vetoing in different threads just dissappears. Again, I can't think of a situation where vetoing is strictly needed (any ideas here would be appreciated). I think we need more brainstorming for the threading issues. Let's say we accept the model as the bus driver. The one that rules actuators. Then that's probably a good hint on how threading should work. The model should be modified by a single thread, I suggest. So probably the easiest thing to do is to use the EDT as the one responsible for modifying the model. So all events to actuators should be genereated in the EDT. That's probably the easiest thing to do, right? State machines I keep on thinking of state machines in the background. Sorry I can't resist! Interesting things I've found about state machines for GUIs and that need further investigation: David Harel (by the way: this guy has interesting papers on Graph Drawing algorithms using spectral methods; quite interesting if you're working in Graph Drawing arena) has interesting publications (and patents) on using Statecharts: A Visual Formalism for Complex Systems. NetBeans Wizards use a state machine in the background. Each step contains a macro-component (the panel contents) and knows nothing about the rest. All navigation (Back/Next/Finish/Cancel) is stored in a WizardDescriptor. Constructing the User Interface with Statecharts seems to be a good reading for me... ;-) Designing simulators in Flash using statecharts with interactive demos. This is interesting. See the wrist watch, for instance. How difficult would be to implement one of those using normal listeners? Statechart Diagrams Problematic! at uidesign.net ForUse 2003 : Lean Interaction Design and Implementation talks about MVC-II, Mediator Pattern and StateCharts! Well, there're many more examples out there. Maybe UI design for mobile phones use statecharts too? I think the next step could be to modify the demo application to make the model drive the bus. Don't you think? Thanks for any suggestions, Antonio