The Incomplete Guide to Flex Events (Part 1 of 4)
When building Flex2 applications, developers have four (4) categories of events that may need to be considered in their custom applications: (1) system events, (2) user events, (3) business events, and (4) data service events.
I personally think the term system event is ambiguous. For example does " system" refer to the OS system or the FlashPlayer system or the MX Framework system... such ambiguity forces me remind the reader that these events are the Flex 2 Framework system events. In the sebsequent paragraphs, we will learn about these four event categories and how they impact our thoughts regarding Flex development.
The Flex2 framework provides superb native support for system, user, and data service events. Developers must create their own business events and must take special care to use the data service events appropriately. This 4-part guide really focuses on the concepts and uses of business and data service event categories. Before we can properly discuss such topics, however, let's first review the concepts and issues with system and user events.
We assume the Flex developer has a base familiarity with system and user events, but may not be aware of the distinctions between the system and user event categories. System events are events that are never generated directly by the user. Instead these events are generated by code activity within the mx framework; events that usually occur during application startup, component creation, component layout/measuring, and more. Such events include creationComplete, initialize, show, hide, etc.
Developers may "hook" or capture these events using built-in event stubs and custom event handlers. The event stub is the location where you specify your event handler and usually has the same name as the event itself. The Flex2 framework provides a multitude of built-in event stubs for both system and user events.
In examples 1 and 2 below the event "stub" [or hook location] is the creationComplete="". The event "handler" is the code inside the "" on the right side of the creationComplete stub. In our examples, we want to insert code that will be executed when the areaAlert component announces that its creation process is done or completed. Example 1 uses inline actionscript to specify our code. Example 2 uses specifies a custom function or method that will be executed when the event handler is invoked. If the event stub is empty [ "" ] - in other words, does not have an event handler - then the creationComplete event is still fired by the component but no event handler is executed.
Below are two equivalent examples of system event hooks:
Example 1
Example 2
Please note: as a course of "best practices", inline actionscript is fine for short 1 code segments [like above]. Explicit method calls as event handlers - e.g. announceReady() - are better used for multiple code segments. This keeps your <mx .../> tags clean and easily managed. Example 3 below shows an multi-line event handler.
Example 3
In various portions of my article I will identify features of the Flex2 platform where compiler MAGIC occurs. By this, I mean activity such as custom tags that are transparently converted to actionscript code or inline actionscript code that is converted during compiler processes... all these can be viewed as "MAGIC" because we never see it happening and it saves us - the developer - an amazing amount of manual work; thus allowing us to keep our code uncluttered with tedious details.
Earlier we stated that examples 1 and 2 are equivalent. When the Flex code in Example 1 is compiled, the inline actionscript is first converted to a distinct method [analogous to the announceReady() method shown in the script section of Example 2]. But you never see this hidden conversion process.... MAGIC!
My next posting will continue with Part 2 of 4: User Events... so stay tuned!
