Events in Flex

Events let a developer know when something happens within a Flex application. They can be generated by user devices, such as the mouse and keyboard, or other external input, such as the return of a web service call. Events are also triggered when changes happen in the appearance or life cycle of a component, such as the creation or destruction of a component or when the component is resized.

Any user interaction with our application can generate events. Events can also occur without any direct user interaction, such as when data finishes loading from a server or when an attached camera becomes active. You can “handle” these events in our code by adding an event handler. Event handlers are the functions or methods that you write to respond to specific events. They are also sometimes referred to as event listeners.
The Flex event model is based on the Document Object Model (DOM) Level 3 Events Model. Although Flex does not adhere specifically to the Document Object Model standard, the implementations are very similar.

Components generate and dispatch events and consume (listen to) other events. An object that requires information about another object’s events registers a listener with that object. When an event occurs, the object dispatches the event to all registered listeners by calling a function that was requested during registration. To receive multiple events from the same object, you must register our listener for each event.

Components have built-in events that you can handle in ActionScript blocks in our MXML applications. You can also take advantage of the Flex event system’s dispatcher-listener model to define our own event listeners outside of our applications, and define which methods of our custom listeners will listen to certain events. You can register listeners with the target object so that when the target object dispatches an event, the listeners get called.

You can instruct any container or control to listen for events dispatched by another container or control. When Adobe Flash Player dispatches an Event object, that Event object makes a round-trip journey from the root of the display list to the target node, checking each node for registered listeners. The target node is the node in the display list where the event occurred.
For example, if a user clicks a Button control named Child1, Flash Player dispatches an Event object with Child1 defined as the target node.

Application tag in Flex

The tag defines the Application container that is always the root tag of a Flex application. In addition to being the root tag of a Flex application, the tag represents an Application container. A container is a user-interface component that contains other components and has built-in layout rules for positioning its child components. By default, an Application container lays out its children vertically from top to bottom. We can write an MXML application in a single file or in multiple files. We typically define a main file that contains the tag. From within our main file, we can then reference additional files written in MXML, ActionScript, or a combination of the two languages.
In Flex, we can divide our application into separate MXML files and ActionScript files, where each file corresponds to a different module. By dividing our application into modules we provide many benefits, including the following:
Ease of development: Different developers or development groups can develop and debug
modules independently of each other.
Reusability: We can reuse modules in different application so that we do not have to
duplicate our work.
Maintainability: We can isolate and debug errors faster than we could if we application was developed in a single file.