Thoughts on event firing
Do UI’s fire events only when someone is listening, or always.
Firing an event often means creating an event object, doing some calculations of what changes were made and what positions they happened in.
Sometimes, one editing event can result in 2 events such as first a delete event and then an insert. Thus, it could be efficient to send events only when an object is listening. Currently, events are fired AFTER default behavior. This hopes to ensure that any exception or problem in a user-defined handler does not result in bypassing default behaviour.
However, i just came across this interesting line on ActionListener. It’s the opposite of what I am doing.
The root event class for all component-level input events. Input events are delivered to listeners before they are processed normally by the source where they originated. This allows listeners and component subclasses to “consume” the event so that the source will not process them in their default manner. For example, consuming mousePressed events on a Button component will prevent the Button from being activated.