EventBus handling

Often a simple order of operations can make a huge difference to the performance of your application. For example, in the StampJ application, many panels or models (for tables and/or trees) listen for a PersistenceEvent on the EventBus. This event might be a Delete, Update or Create operation. Now the way in which one listens to the event is key. Ideally, the listener will identify that the event is targetted toward a specific entity class relevant to the listener (for example a list of countries can ignore events raised by stamps). If the event is valid, then the actual event type can be determined and the appropriate action taken (such as updating the table, changing a value etc.) Ensuring only a single table model is present in the table is also a good idea. I uncovered a situation where I was creating a table model as part of the constructor of a StampListTable. Then within the StampResultPanel (which has a StampListTable) I was calling initialize( ) which just so happened to create a second StampListTableModel. While this looked beneign, what happened is since my StampListTableModel is listening for various persistent events, the model(s) were each processing the events, thus twice the secondary tasks were being executed. Of course, the way I discovered this was quite by accident. I happened to be trying to discovered why the reference catalogue numbers were sometimes out of wack with the persistence datastore. In debugging this I discovered that the event was being listened to twice.