* Dispatched when the module throws an error.Įvent(name="error", type="mx.events.ModuleEvent") * Dispatched when the module is finished loading.Įvent(name="ready", type="mx.events.ModuleEvent") * Dispatched when information about the module isĮvent(name="setup", type="mx.events.ModuleEvent")
* Dispatched when the ModuleLoader is given a new URL.Įvent(name="urlChanged", type="") * Dispatched when the ModuleLoader starts to load a URL.Įvent(name="loading", type="") The APIs are a combination of INavigatorContent and mx:ModuleLoader. The events are exactly the same as mx:ModuleLoader.
#Moduleloader plus license
// NOTICE : Adobe permits you to use, modify, and distribute this file // in accordance with the terms of the license agreement accompanying it. It mainly gives us a new tag and a place to hang the Frame metadata. All of its visuals are dictated by the Spark Module that it loads. Spark ModuleLoader will extend Group as it doesn't need a skin. Spark ModuleLoader will implement INavigatorContent so it can be used directly in mx-based Navigators. This is because NavigatorContent also extends SkinnableContainer and we want to allow all attributes and tags of the NavigatorContent including the skinClass to be simply copied and pasted into a module file (except for the label and icon properties which should remain on the child of the navigator). Spark Module will extend SkinnableContainer. We will focus entirely on the most common case of carving up a set of navigator views. There is a solution on my blog that folks will continue to use for Spark that does not involve Module or ModuleLoader. s:Module will also wrap the s:TitleWindow or s:Panel and prevent dragging and focus. The popup-as-modules scenario will remain difficult with Spark as well. This is currently hard to do even with mx:Module as mx:Module ends up wrapping an mx:TitleWindow or mx:Panel which defeats its ability to be dragged or have its own focus manager.
The second most common scenario for UI modules is to bring in popups as modules. Detailed DescriptionĬarving up a set of navigator views into modules is the most common use of mx:Module and mx:ModuleLoader today. Work with your Catalyst contacts to complete a workflow specification that describes how this feature will be exposed to users in Catalyst. Work with your Flash Builder contacts to complete a workflow document that describes how this feature will be exposed to users in Flash Builder. This makes him very happy because in Flex 4.1, he would have had to use mx:Module as the main class in the module files and placed a SkinnableContainer inside the mx:Module which would have added another layer to the display object tree. And modifies the main app to look like this:
0 kommentar(er)
