The event flow is conceptually divided into three parts.
Capturing phase:
The first part of the event flow is called the capturing phase, which comprises all of the nodes from the root node to the parent of the target node. During this phase, Flash Player examines each node, starting with the root, to see if it has a listener registered to handle the event. If it does, Flash Player sets the appropriate values of the Event object and then calls that listener. Flash Player stops after it reaches the target node’s parent and calls any listeners registered on the parent.
Targeting phase:
The second part of the event flow is called the targeting phase, which consists solely of the target node. Flash Player sets the appropriate values on the Event object, checks the target node for registered event listeners, and then calls those listeners.
Bubbling phase:
The third part of the event flow is called the bubbling phase, which comprises all of the nodes from the target node’s parent to the root node. Starting with the target node’s parent, Flash Player sets the appropriate values on the Event object and then calls event listeners on each of these nodes. Flash Player stops after calling any listeners on the root node.
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.
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.
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.
How do we use a repeater?
< mx:repeater id="rp" dataprovider="{dp}">
< height="49" width="50" click="Alert.show(String(event.currentTarget.getRepeaterItem())+ ' pressed')"
label="{String (rp.currentItem)}">
< /mx:repeater>
< height="49" width="50" click="Alert.show(String(event.currentTarget.getRepeaterItem())+ ' pressed')"
label="{String (rp.currentItem)}">
< /mx:repeater>
I need to load an image from flickr into my application. Do I need a crossdomain.xml file on flickr?
When we load images at run time, we should be aware of the security restrictions of Flash Player. For example, we can reference an image by using a URL, but the default security settings only permit Flex applications to access resources stored on the same domain as our application. To access images on other servers, we must use a crossdomain.xml file.
Every SWF file we view runs locally on our machine. This means that a SWF would have HTTP access to all machines behind the company firewall. To prevent this, every server other than the one the SWF is loaded from, needs to have a crossdomain.xml file in its root, listing all domains that have access to that particular server.
NOTE
We can use relative URLs for images hosted on the same web server as the Flex application, but we must load these images over the Internet rather than access them locally.
Loading Remote Style Sheets
If the style sheet is local(from the same domain as the loading application), we can load it without any additional settings. If the location of the style sheet is remote (in any domain that is not an exact match of the loading application’s domain), we must set the third parameter of the loadStyleDeclarations() method, trustContent, to true. Loading remote style sheets does not require a crossdomain.xml file that gives the loading application permission to load the SWF file.
StyleManager.loadStyleDeclarations("assets/ButtonStyles.swf", true, false)
Also, to use remote style sheets, we must compile the loading application with network access (have the use-network compiler property set to true, the default). If we compile and run the application on a local file system, we might not be able to load a remotely accessible SWF file.
The loadStyleDeclarations() method returns an instance of the IEventDispatcher class.
We can use this object to trigger events based on the success of the style sheet’s loading. We have access to the StyleEvent.PROGRESS, StyleEvent.COMPLETE, and StyleEvent.ERROR events of the loading process.
We can unload a style sheet that we loaded at run time. We do this by using the
StyleManager’s unloadStyleDeclarations() method. The result of this method is that all
style properties set by the specified style SWF files are returned to their defaults.
StyleManager.unloadStyleDeclarations("assets/ButtonStyles.swf", true);
Every SWF file we view runs locally on our machine. This means that a SWF would have HTTP access to all machines behind the company firewall. To prevent this, every server other than the one the SWF is loaded from, needs to have a crossdomain.xml file in its root, listing all domains that have access to that particular server.
NOTE
We can use relative URLs for images hosted on the same web server as the Flex application, but we must load these images over the Internet rather than access them locally.
Loading Remote Style Sheets
If the style sheet is local(from the same domain as the loading application), we can load it without any additional settings. If the location of the style sheet is remote (in any domain that is not an exact match of the loading application’s domain), we must set the third parameter of the loadStyleDeclarations() method, trustContent, to true. Loading remote style sheets does not require a crossdomain.xml file that gives the loading application permission to load the SWF file.
StyleManager.loadStyleDeclarations("assets/ButtonStyles.swf", true, false)
Also, to use remote style sheets, we must compile the loading application with network access (have the use-network compiler property set to true, the default). If we compile and run the application on a local file system, we might not be able to load a remotely accessible SWF file.
The loadStyleDeclarations() method returns an instance of the IEventDispatcher class.
We can use this object to trigger events based on the success of the style sheet’s loading. We have access to the StyleEvent.PROGRESS, StyleEvent.COMPLETE, and StyleEvent.ERROR events of the loading process.
We can unload a style sheet that we loaded at run time. We do this by using the
StyleManager’s unloadStyleDeclarations() method. The result of this method is that all
style properties set by the specified style SWF files are returned to their defaults.
StyleManager.unloadStyleDeclarations("assets/ButtonStyles.swf", true);
What is e4X and XML?
E4X means "ECMAScript For XML. Using E4X, we can develop code with XML data faster than was possible with previous programming techniques. E4X provides a set of classes and functionality for working with XML data. ActionScript 3.0 includes the following E4X classes: XML, XMLList, QName, and Namespace.
What is cairngorm? How do we use it? or Explain the lifecycle of a Cairngorm action?
Some of the frameworks in Flex are : EasyMVC, Cairngorm, Mate, Swiz. I had worked only on cairngorm and so putting down its details:
Overview of Cairngorm
What is Cairngorm? Cairngorm is fundamentally a methodology for breaking up our application code by logical functions; by data, by user views, and by the code that controls everything. This is routinely referred to as MVC, or Model, View, and Control.
The Pieces of Cairngorm
•Model Locator: Stores all of our application’s Value Objects (data) and shared variables, in one place. Similar to an HTTP Session object, except that its stored client side in the Flex interface instead of server side within a middle tier application server.
• View: One or more Flex components (button, panel, combo box, Tile, etc) bundled together as a named unit, bound to data in the Model Locator, andgenerating custom Cairngorm Events based on user interaction (clicks, rollovers, dragndrop.)
• Front Controller: Receives Cairngorm Events and maps them to Cairngorm Commands.
• Command: Handles business logic, calls Cairngorm Delegates and/or other Commands, and updates the Value Objects and variables stored in the ModelLocator
• Delegate: Created by a Command, they instantiate remote procedure calls(HTTP, Web Services, etc) and hand the results back to that Command.
• Service: Defines the remote procedure calls (HTTP, Web Services, etc) to connect to remote data stores.
How the Pieces Fit Together
Cairngorm basically works like this: Our client interface is comprised of Views. The Views use Flex binding to display data contained in the Model Locator. The Views generate Events based on user gestures such as mouse click, button press, and drag & drop. Those Events are “broadcast” and “heard” by the Front Controller, which is a map of Events to Commands. Commands contain business logic, create Delegates to perform work, handle responses from Delegates, and update the data stored in the ModelLocator. Since Views are bound to the data in the ModelLocator the Views automatically update when the ModelLocator data is changed. Delegates call Services and hand results back to Commands, and are optional but recommended. Services make remote data calls and hand the results back to Delegates.
Overview of Cairngorm
What is Cairngorm? Cairngorm is fundamentally a methodology for breaking up our application code by logical functions; by data, by user views, and by the code that controls everything. This is routinely referred to as MVC, or Model, View, and Control.
The Pieces of Cairngorm
•Model Locator: Stores all of our application’s Value Objects (data) and shared variables, in one place. Similar to an HTTP Session object, except that its stored client side in the Flex interface instead of server side within a middle tier application server.
• View: One or more Flex components (button, panel, combo box, Tile, etc) bundled together as a named unit, bound to data in the Model Locator, andgenerating custom Cairngorm Events based on user interaction (clicks, rollovers, dragndrop.)
• Front Controller: Receives Cairngorm Events and maps them to Cairngorm Commands.
• Command: Handles business logic, calls Cairngorm Delegates and/or other Commands, and updates the Value Objects and variables stored in the ModelLocator
• Delegate: Created by a Command, they instantiate remote procedure calls(HTTP, Web Services, etc) and hand the results back to that Command.
• Service: Defines the remote procedure calls (HTTP, Web Services, etc) to connect to remote data stores.
How the Pieces Fit Together
Cairngorm basically works like this: Our client interface is comprised of Views. The Views use Flex binding to display data contained in the Model Locator. The Views generate Events based on user gestures such as mouse click, button press, and drag & drop. Those Events are “broadcast” and “heard” by the Front Controller, which is a map of Events to Commands. Commands contain business logic, create Delegates to perform work, handle responses from Delegates, and update the data stored in the ModelLocator. Since Views are bound to the data in the ModelLocator the Views automatically update when the ModelLocator data is changed. Delegates call Services and hand results back to Commands, and are optional but recommended. Services make remote data calls and hand the results back to Delegates.
Subscribe to:
Posts (Atom)
