Eventsystem

EventTarget

FUDGE uses or closely resembles and implements the well known event system of the browsers document object model. Therefore, many classes of FUDGE extend EventTarget and thus use or implement the core methods addEventListener, removeEventListener and dispatchEvent.

Users can register methods to an EventTarget to be called automatically when a certain event occurs. For example, the static class Loop may periodically fire an event as the main heartbeat of the game. Any method that was registered to the loop for this event will be called and an object of the type Event is passed to it, carrying more information. This method may be a function that takes care of updating moving objects and rendering a branch.

Event Propagation

As in the DOM-Tree, some events can travel via [node](Node and Branch)s through the graph in different phases. For example, adding a node to a branch as a child causes the creation of an event.

1. In the capture phase, the event gets first passed to the root node, then down the hierarchy until it reaches the newly created node.
2. The target phase is when the event gets passed to this node, which is called the target of the event.
3. Then, the event gets passed back up the hierarchy in the bubbling phase.

Up and down are used in terms of a tree graph drawn upside down.

When adding an EventListener, thus registering a handler for an event, it is possible to determine the phase of propagation in which the event will activate the listener.

Broadcasting

In addition to the standard model, with FUDGE it is also possible to broadcast an event into a branch. This event then recursively travels to all child nodes of the branch and their children and so on, respectively to all successors.

Example

For further explanation, consider the following scenario: in a game the player sees a control panel with three buttons dimly lit. Pressing one button (e.g. by mouseclick) highlights that one while the others turn completely dark. Using a proper hierarchy of nodes, script components and the event system, this is one way to easily and safely achieve that:

At the start of the program (not depicted), the scripts register handlers for the click-event in the target- and bubbling-phase at their container nodes, the buttons additionally for the custom "off"-event in the capture-phase.

• When a user clicks a button (0),
• a click event travels down the hierarchy (1)
• and hits the target button in the target phase (2). The handler activates, highlights that button and removes the "off"-listener from the target node.
• The click-event then bubbles back up to the panel (3), where its handler gets activated. According to the information passed with the event-object, the panel script triggers the action appropriate for the target button and
• broadcasts the "off"-event (4). The highlighted button does not react, since its handler has just been removed. The other two deactivate.