锘??xml version="1.0" encoding="utf-8" standalone="yes"?> "Thermo" is an upcoming Adobe product that makes it easy for
designers to create rich Internet application UIs. Thermo allows
designers to build on familiar workflows to visually create working
applications that easily flow into production and development.
Applications created in Thermo are Flex applications that can be
loaded directly into Flex Builder, providing a great roundtrip workflow
for designers collaborating with developers. The designer's work can be
incorporated directly into the production application with no loss of
fidelity, and designers can continue to refine the design throughout
the iterative development process.
Check back for more details on Thermo soon!
]]>
]]>
]]>
]]>
]]>
http://labs.adobe.com
Flash Builder 4瀹夎鍖呭皢浼氭牴鎹綘鎿嶄綔緋葷粺鐨勮璦閰嶇疆涓鴻嫳鏂囧拰綆浣撲腑鏂囩殑閫夋嫨銆備笅闈㈡槸閮ㄥ垎鏉ヨ嚜Release Notes鐨勭炕璇戙?br />
鏂板鍔熻兘錛?br />
Flex SDK
* 寮曞叆涓涓叏鏂扮殑鍔熻兘寮哄ぇ鐨勭粍浠剁毊鑲ゆ鏋訛紝鍙仛Spark銆?br />
* 鍩轟簬Spark妗嗘灦榪涜鍒濆鍖栫殑緇勪歡鍙互涓嶧lex3涓殑Halo緇勪歡闆嗗悎娣峰悎鍜屽尮閰嶄嬌鐢ㄣ?br />
* 鏀寔澹版槑鍖栫殑錛屽姩鎬佺殑MXML鍥懼艦錛屼互鍙奆XG鏍煎紡鐨勫浘褰€?br />
* 鍏ㄦ柊鐨凷park榛樿澶栬錛屾敮鎸佸叏鏂扮殑鏍峰紡闆嗗悎銆?br />
* 鏇村己澶х殑甯冨眬鏀寔錛屽寘鎷敮鎸丮XML鍥懼艦鍏冪礌錛屽寮哄浜庣炕杞拰鍏朵粬鍙樺艦鐨勬敮鎸侊紝鏀寔鎸囧畾鑷畾涔夌殑甯冨眬錛屽寮簔杞寸鐞嗐?br />
* 涓浜涙柊鐨勫拰澧炲己鐨勭壒鏁堬紝鍖呮嫭鏀寔MXML鍥懼艦鍏冪礌鐨勫姩鐢伙紝閫氳繃鑷畾涔夌殑鍔ㄧ敾淇敼錛屾洿澶氭槗鐢ㄧ殑API璋冪敤鏂瑰紡錛屾洿澶氱殑鑷姩鍖栫殑浜や簰琛屼負銆?br />
* 3D鐗規晥鏀寔
* Flash鍔ㄧ敾婊ら暅錛屽寘鎷琍ixel Bender銆?br />
* 鏇村楂樼駭瀛椾綋鏀寔銆傚熀浜嶧lash Text 寮曟搸鍜孴ext甯冨眬妗嗘灦錛屼篃鏀寔CFF錛圕ompact Font Format錛夈?br />
* 緙栬瘧鍣ㄦц兘鎻愬崌銆?br />
* 鏂扮殑MXML璇█鍔熻兘錛屽寘鎷琈XML 2009鍛藉悕絀洪棿錛屽0鏄庯紝搴撳拰鏍囩瀹氫箟銆?br />
* CSS澧炲己錛屽寘鎷敮鎸佸懡鍚嶇┖闂達紝緇ф壙閫夋嫨鍣紝ID閫夋嫨鍣紝鏇村鐨勭被閫夋嫨鍣ㄥ拰閽堝緇勪歡鐘舵佺殑浼夋嫨鍣ㄦ敮鎸併?br />
* 璇硶澧炲己鍜岀姸鎬乻tates澧炲己銆?br />
* 鏂逛究鐨勬暟鎹弻鍚戠粦瀹氳娉曘?br />
* ASDoc鏀寔鍦╩xml鏂囦歡閲岀殑緇勪歡銆?br />
* 澧炲己鐨凥TML妯℃澘錛屽熀浜嶴WFObject銆?br />
* adobe.com瀛樻斁 SDK榪愯鏃跺叡浜簱RSL銆?br />
* 棰濆鐨勬湰鍦板寲鏀寔錛屾洿濂界殑寮鍙戞湰鍦板寲搴旂敤銆?br />
Flash Builder鏂板姛鑳?br />
* 涓涓潰鍚戝垱寤烘暟鎹湇鍔″簲鐢ㄧ殑鏂板伐浣滄祦錛堝寘鎷珻F,PHP,Java,WebServices錛夈?br />
* 鏀寔鐢盕lash Catalyst鍒涘緩鐨凢XG欏圭洰
* 涓涓叏鏂扮殑Network鐩戞帶錛屽府鍔╄瘖鏂鎴風鍜屾湇鍔″櫒孌電殑閫氳闂
* Flex 鍗曞厓嫻嬭瘯鏁村悎銆?br />
* 鑷姩鐢熸垚getter鍜宻etter銆?br />
* ASDoc鏀寔鍦∕XML鍜孉S涓樉紺篈SDoc娉ㄩ噴
* 鑷畾涔夋枃浠舵ā鏉挎敮鎸丮XML錛孉S鍜孋SS鏂囦歡銆?br />
* 鑷姩鐢熸垚浜嬩歡澶勭悊鍑芥暟緇撴瀯銆?br />
* 璋冭瘯鍣ㄥ寮恒?br />
* Profiler澧炲己銆?br />
* Refactoring澧炲己
* 鏂扮殑Component kit for Flash CS4
* 鏂版敮鎸佸懡浠よ鏋勫緩鎵ц鏂瑰紡銆?br />
* 瀵煎叆鍜屽簲鐢‵lex涓婚鏂扮敤鎴風晫闈€?br />
* 鏂扮殑Flex綾誨寘嫻忚鍣ㄦ浛浠lex Navigator闈㈡澘銆?
]]>
]]>
]]>
]]>
]]>
From Adobe Labs
Product Codename: "Thermo"
Features
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
鍏充簬浜嬩歡嫻?/strong>
addEventListener(
type:String, 浜嬩歡鐨勭被鍨?br id="vsyt0" />
listener:Function, 鐩戝惉鍑芥暟
useCapture:Boolean = false, 鏄惁鎵撳紑鎹曡幏鍔熻兘
priority:int = 0, 鐩戝惉鍣ㄤ紭鍏堢駭鍒?br id="vsyt3" />
useWeakReference:Boolean = false 鏄惁浣跨敤寮卞紩鐢?br id="vsyt4" />
)
濡傛灉useCapture 涓簍rue錛屾墦寮浜嗘崟鑾峰姛鑳斤紝鍒欒緇勪歡鐨勫啋娉¢樁孌佃鍙栨秷銆?br id="e-a:" />
鍙湁鍙鍖栫殑瀵硅薄鏈?涓樁孌碉紝鑰屽儚XML絳夐潪鍙鍖栧璞″彧鏈夌洰鏍囬樁孌點?/p>
8.2.2 浜嬩歡瀵硅薄
8.2.3 渚﹀惉鍜屽搷搴斾簨浠?-涓涓睛鍚敭鐩樹簨浠剁殑渚嬪瓙
Modules are SWF files that can be loaded and unloaded by an application. They cannot be run independently of an application, but any number of applications can share the modules.
Modules let you split your application into several pieces, or modules. The main application, or shell, can dynamically load other modules that it requires, when it needs them. It does not have to load all modules when it starts, nor does it have to load any modules if the user does not interact with them. When the application no longer needs a module, it can unload the module to free up memory and resources.
Modular applications have the following benefits:
Modules are similar to Runtime Shared Libraries (RSLs) in that they separate code from an application into separately loaded SWF files. Modules are much more flexible than RSLs because modules can be loaded and unloaded at run time and compiled without the application.
Two common scenarios in which using modules is beneficial are a large application with different user paths and a portal application.
An example of the first common scenario is an enormous insurance application that includes thousands of screens, for life insurance, car insurance, health insurance, dental insurance, travel insurance, and veterinary pet insurance.
Using a traditional approach to rich Internet application (RIA) design, you might build a monolithic application with a hierarchical tree of MXML classes. Memory use and start-up time for the application would be significant, and the SWF file size would grow with each new set of functionality.
When using this application, however, any user accesses only a subset of the screens. By refactoring the screens into small groups of modules that are loaded on demand, you can improve the perceived performance of the main application and reduce the memory use. Also, when the application is separated into modules, developers' productivity may increase due to better encapsulation of design. When rebuilding the application, the developers also have to recompile only the single module instead of the entire application.
An example of the second common scenario is a system with a main portal application, written in ActionScript 3, that provides services for numerous portlets. Portlets are configured based on data that is downloaded on a per-user basis. Using the traditional approach, you might build an application that compiles in all known portlets. This is inefficient, both for deployment and development.
By using modules, you can establish an interface that contains portal services, and a generic portlet interface. You can use XML data to determine which modules to load for a given session. When the module is loaded, you obtain a handle to a class factory inside the module, and from that you create an instance of a class that implements the portlet interface. In this scenario, full recompilation is necessary only if the interfaces change.
Modules implement a class factory with a standard interface. The product of that class factory implements an interface known to the shell, or the shell implements an interface known to the modules.
By using shared interface definitions, these shared interfaces reduce hard dependencies between the shell and the module. This provides type-safe communication and enforces an abstraction layer without adding significantly to the SWF file size.
The following image shows the relationship between the shell and the module's interfaces:
To create a modular application, you create separate classes for each module, plus an application that loads the modules.
<mx:Module>
. ActionScript-based modules extend the ModuleBase class.<mx:Application>
, but it can also be an ActionScript-only application.<mx:ModuleLoader>
tag to load each of the modules. You can also do this by using the load()
method of the mx.modules.ModuleLoader class. For classes that extend
ModuleBase, you should use the methods of the ModuleManager class to
load them.The following sections describes these steps in detail.
Modules are classes just like application files. To create a module
in ActionScript, you create a file that extends the
mx.modules.ModuleBase class. To create a module in MXML, you extend the
mx.modules.Module class by creating a file whose root tag is <mx:Module>
.
In that tag, ensure that you add any namespaces that are used in that
module. You should also include a type declaration tag at the beginning
of the file.
The following example is a module that includes a Chart control:
<?xml version="1.0"?>
<!-- modules/ColumnChartModule.mxml -->
<mx:Module xmlns:mx="http://www.adobe.com/2006/mxml" width="100%" height="100%" >
<mx:Script><![CDATA[
import mx.collections.ArrayCollection;
[Bindable]
public var expenses:ArrayCollection = new ArrayCollection([
{Month:"Jan", Profit:2000, Expenses:1500},
{Month:"Feb", Profit:1000, Expenses:200},
{Month:"Mar", Profit:1500, Expenses:500}
]);
]]></mx:Script>
<mx:ColumnChart id="myChart" dataProvider="{expenses}">
<mx:horizontalAxis>
<mx:CategoryAxis
dataProvider="{expenses}"
categoryField="Month"
/>
</mx:horizontalAxis>
<mx:series>
<mx:ColumnSeries
xField="Month"
yField="Profit"
displayName="Profit"
/>
<mx:ColumnSeries
xField="Month"
yField="Expenses"
displayName="Expenses"
/>
</mx:series>
</mx:ColumnChart>
<mx:Legend dataProvider="{myChart}"/>
</mx:Module>
You compile the module as you would compile any Flex application using the mxmlc command-line compiler or the Flex Builder compiler. The following command is the simplest mxmlc command:
mxmlc MyModule.mxml
The result is a SWF file that you load into your application as a module. You cannot run the module-based SWF file as a stand-alone Flash application or load it into a browser window. It must be loaded by an application as a module.
Module size varies based on the components and classes that are used in the module. By default, a module includes all framework code that its components depend on, which can cause modules to be large by linking classes that overlap with the application's classes.
To reduce the size of the modules, you can instruct the module to externalize classes that are included by the application. This includes custom classes and framework classes. The result is that the module only includes the classes it requires, while the framework code and other dependencies are included in the application.
To externalize framework classes, you generate a linker report from
the application that loads the modules, by using mxmlc commands. You
then use this report as input to the module's load-externs
compiler option.
mxmlc -link-report=report.xml MyApplication.mxml
mxmlc MyApplication.mxml
mxmlc -load-externs=report.xml MyModule.mxml
You must recompile the modules if you make changes. Recompiling the main application does not trigger a recompilation of the modules. Similarly, if you change the application file, you do not have to recompile the modules, unless you make changes that might affect the linker report or common code.
NOTE |
|
If you externalize the module's dependencies by using the |
MXML-based modules can load other modules. Those modules can load other modules, and so on.
To load and unload modules you use the load()
and unload()
methods of the ModuleLoader class. These methods take no parameters;
the ModuleLoader loads or unloads the module that matches the value of
the current url
property.
The following example loads and unloads the module when you click the button:
<?xml version="1.0"?>
<!-- modules/ASModuleLoaderApp.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Script>
<![CDATA[
import mx.modules.*;
public function createModule(m:ModuleLoader, s:String):void {
if (!m.url) {
m.url = s;
return;
}
m.loadModule();
}
public function removeModule(m:ModuleLoader):void {
m.unloadModule();
}
]]>
</mx:Script>
<mx:Panel title="Module Example"
height="90%"
width="90%"
paddingTop="10"
paddingLeft="10"
paddingRight="10"
paddingBottom="10"
>
<mx:TabNavigator id="tn"
width="100%"
height="100%"
creationPolicy="auto"
>
<mx:VBox id="vb1" label="Column Chart Module">
<mx:Button
label="Load"
click="createModule(chartModuleLoader, l1.text)"
/>
<mx:Button
label="Unload"
click="removeModule(chartModuleLoader)"
/>
<mx:Label id="l1" text="ColumnChartModule.swf"/>
<mx:ModuleLoader id="chartModuleLoader"/>
</mx:VBox>
<mx:VBox id="vb2" label="Form Module">
<mx:Button
label="Load"
click="createModule(formModuleLoader, l2.text)"
/>
<mx:Button
label="Unload"
click="removeModule(formModuleLoader)"
/>
<mx:Label id="l2" text="FormModule.swf"/>
<mx:ModuleLoader id="formModuleLoader"/>
</mx:VBox>
</mx:TabNavigator>
</mx:Panel>
</mx:Application>
Setting the location of a ModuleLoader triggers a call to the loadModule()
method, too. This occurs when you first create a ModuleLoader with the url
property set. It also occurs if you change the value of that property.
The following example loads the modules without calling the loadModule()
method because the url
property is set on the <mx:ModuleLoader>
tags:
<?xml version="1.0"?>
<!-- modules/URLModuleLoaderApp.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Panel
title="Module Example"
height="90%"
width="90%"
paddingTop="10"
paddingLeft="10"
paddingRight="10"
paddingBottom="10"
>
<mx:Label width="100%" color="blue"
text="Select the tabs to change the panel."/>
<mx:TabNavigator id="tn"
width="100%"
height="100%"
creationPolicy="auto"
>
<mx:VBox id="vb1" label="Column Chart Module">
<mx:Label id="l1" text="ColumnChartModule.swf"/>
<mx:ModuleLoader url="ColumnChartModule.swf"/>
</mx:VBox>
<mx:VBox id="vb2" label="Form Module">
<mx:Label id="l2" text="FormModule.swf"/>
<mx:ModuleLoader url="FormModule.swf"/>
</mx:VBox>
</mx:TabNavigator>
</mx:Panel>
</mx:Application>
When you load a module, Flex ensures that there is only one copy of a module loaded, no matter how many times you call the load()
method for that module.
Modules are loaded into the child of the current application domain.
You can specify a different application domain by using the applicationDomain
property of the ModuleLoader class.
When two classes of the same name but different implementations are loaded, the first one loaded is the one that is used.
To load a module from one server into an application running on a different server, you must establish a trust between the module and the application that loads it.
allowDomain()
method and specify the target domain from which you load a module. So,
specify the target domain in the preinitialize event handler of your
application to ensure that the application is set up before the module
is loaded. allowDomain()
method so that it can communicate with the loader. The following example shows the init()
method of the loading application:
public function setup():void {
Security.allowDomain("remoteservername");
Security.loadPolicyFile("http://remoteservername/crossdomain.xml");
var request:URLRequest = new URLRequest("http://remoteservername
/crossdomain.xml");
var loader:URLLoader = new URLLoader();
loader.load(request);
}
The following example shows the loaded module's init()
method:
public function initMod():void {
Security.allowDomain("loaderservername");
}
The following example shows the cross-domain file that resides on the remote server:
<!-- crossdomain.xml file located at the root of the server -->
<cross-domain-policy>
<allow-access-from domain="loaderservername" to-ports="*"/>
</cross-domain-policy>
For more information about using the cross-domain policy file, see Applying Flex Security in Building and Deploying Flex 2 Applications.
The ModuleLoader class triggers several events, including setup
, ready
, loading
, unload
, progress
, error
, and urlChanged
.
You can use these events to track the progress of the loading process,
and find out when a module has been unloaded or when the ModuleLoader's
target URL has changed.
The error
event gives you an opportunity to gracefully
fail when a module does not load for some reason. In the following
example, you can load and unload a module by using the Button controls.
To trigger an error
event, change the URL in the
TextInput control to a module that does not exist. The error handler
displays a message to the user and writes the error message to the
trace log.
Revision 1/10/2007: Minor change to createModule() method.
<?xml version="1.0"?>
<!-- modules/ErrorEventHandler.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Script>
<![CDATA[
import mx.events.ModuleEvent;
import mx.modules.*;
import mx.controls.Alert;
private function errorHandler(e:ModuleEvent):void {
Alert.show("There was an error loading the module." +
" Please contact the Help Desk.");
trace(e.errorText);
}
public function createModule():void {
if (chartModuleLoader.url == ti1.text) {
// If they are the same, call loadModule.
chartModuleLoader.loadModule();
} else {
// If they are not the same, then change the url,
// which triggers a call to the loadModule() method.
chartModuleLoader.url = ti1.text;
}
}
public function removeModule():void {
chartModuleLoader.unloadModule();
}
]]>
</mx:Script>
<mx:Panel title="Module Example"
height="90%"
width="90%"
paddingTop="10"
paddingLeft="10"
paddingRight="10"
paddingBottom="10"
>
<mx:HBox>
<mx:Label text="URL:"/>
<mx:TextInput width="200" id="ti1" text="ColumnChartModule.swf"/>
<mx:Button label="Load" click="createModule()"/>
<mx:Button label="Unload" click="removeModule()"/>
</mx:HBox>
<mx:ModuleLoader id="chartModuleLoader" error="errorHandler(event)"/>
</mx:Panel>
</mx:Application>
You can use the progress
event to track the progress of a module as it loads. When you add a listener for the progress
event, Flex calls that listener at regular intervals during the
module's loading process. Each time the listener is called, you can
look at the bytesLoaded
property of the event. You can compare this to the bytesTotal
property to get a percentage of completion.
The following example reports the level of completion during the module's loading process. It also produces a simple progress bar that shows users how close the loading is to being complete.
<?xml version="1.0"?>
<!-- modules/SimpleProgressEventHandler.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Script>
<![CDATA[
import mx.events.ModuleEvent;
import flash.events.ProgressEvent;
import mx.modules.*;
[Bindable]
public var progBar:String = "";
[Bindable]
public var progMessage:String = "";
private function progressEventHandler(e:ProgressEvent):void {
progBar += ".";
progMessage =
"Module " +
Math.round((e.bytesLoaded/e.bytesTotal) * 100) +
"% loaded";
}
public function createModule():void {
chartModuleLoader.loadModule();
}
public function removeModule():void {
chartModuleLoader.unloadModule();
progBar = "";
progMessage = "";
}
]]>
</mx:Script>
<mx:Panel title="Module Example"
height="90%"
width="90%"
paddingTop="10"
paddingLeft="10"
paddingRight="10"
paddingBottom="10"
>
<mx:HBox>
<mx:Label id="l2" text="{progMessage}"/>
<mx:Label id="l1" text="{progBar}"/>
</mx:HBox>
<mx:Button label="Load" click="createModule()"/>
<mx:Button label="Unload" click="removeModule()"/>
<mx:ModuleLoader
id="chartModuleLoader"
url="ColumnChartModule.swf"
progress="progressEventHandler(event)"
/>
</mx:Panel>
</mx:Application>
You can also connect a module loader to a ProgressBar control. The following example creates a custom component for the ModuleLoader that includes a ProgressBar control. The ProgressBar control displays the progress of the module loading.
<?xml version="1.0"?>
<!-- modules/MySimpleModuleLoader.mxml -->
<mx:ModuleLoader xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Script>
<![CDATA[
private function clickHandler():void {
if (!url) {
url="ColumnChartModule.swf";
}
loadModule();
}
]]>
</mx:Script>
<mx:ProgressBar
id="progress"
width="100%"
source="{this}"
/>
<mx:HBox width="100%">
<mx:Button
id="load"
label="Load"
click="clickHandler()"
/>
<mx:Button
id="unload"
label="Unload"
click="unloadModule()"
/>
<mx:Button
id="reload"
label="Reload"
click="unloadModule();loadModule();"
/>
</mx:HBox>
</mx:ModuleLoader>
You can use this module in a simple application, as the following example shows:
<?xml version="1.0"?>
<!-- modules/ComplexProgressEventHandler.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:local="*">
<mx:Panel title="Module Example"
height="90%"
width="90%"
paddingTop="10"
paddingLeft="10"
paddingRight="10"
paddingBottom="10"
>
<mx:Label text="Use the buttons below to load and unload
the module."/>
<local:MySimpleModuleLoader id="customLoader"/>
</mx:Panel>
</mx:Application>
This example does not change the ProgressBar's label
property for all events. For example, if you load and then unload the module, the label
property remains at "LOADING 100%". To adjust the label properly, you
must define other event handlers for the ModuleLoader events, such as unload
and error
.