* 處理協議
*/
private function init(){
var surl:String = ExternalInterface.call("eval", "window.location.href");
var cs:ChannelSet = new ChannelSet();
var c:Channel = null;
if(URLUtil.getProtocol(surl)=="https"){
c = new SecureAMFChannel();
c.uri="/SSS/messagebroker/amfsecure";
}else{
c = new AMFChannel();
c.uri="/SSS/messagebroker/amf";
}
cs.addChannel(c);
remote.channelSet=cs;
.;}
請注意！引用、轉貼本文應注明原作者：Rosen Jiang 以及出處： http://www.tkk7.com/rosen
]]>
寫作本文的目的是為了能讓自己對基礎的概念更加熟悉，盡管近期都在關注Flex領域，不過得承認，HTML和JavaScript方面的能力很重要，并不是所有的開發者都認同我的說辭：“復雜的業務我傾向用Flex實現。”——rosen jiang
什么是DOM？
從我參加工作開始嘴上就老是掛著DOM，起先認為DOM只是針對XML領域，后來才知道HTML也是一種DOM結構。W
什么是文檔(Ducument)？
文檔就是一段合法的XML串或一段HTML，在概念上文檔應該有根以便能訪問到里面的數據。
DOM的級別
DOM
Level 1，DOM
Level 1第一版又分成DOM
Level 1 Core和DOM
Level 1 HTML。
DOM Level 1 Core定義了一組最基本的訪問和操作文檔的對象和接口，是一種滿足所有軟件開發者和web腳本開發者訪問和操作HTML、XML的功能性規范。
DOM Level 1 HTML繼承了DOM Level 1 Core，主要描述HTML文檔方面的對象和方法。一般來說，DOM Level 1 HTML要能實現維護結構化的文檔、元素和屬性。
DOM
Level 2，DOM
Level 2又分成DOM
Level 2 Core、DOM
Level 2 Views、DOM
Level 2 Events、DOM Level 2 Style、DOM
Level 2 Traversal and Range Specification、DOM
Level 2 HTML。在這里我只關注Core和HTML。
DOM Level 2 Core和Level 1的定義一樣，并基于Level 1構建。
DOM Level 2 HTML基于DOM Level 2 Core構建，且不與DOM Level 1 HTML兼容，DOM Level 2 HTML也是目前HTML 4.01和XHTML 1.0所采用的級別。
DOM
Level 3，在這里就不多描述了，目前還沒有DOM Level 3 HTML規范，我看DOM Level 3 Core的描述還是針對HTML 4.01的，難道是在等傳說中的HTML 5？對于HTML 5的相互爭論是可以的，奉勸各大瀏覽器廠商不要把頭打破了。
HTML
DOM對象包括所有的標簽，例如<a>就是一個DOM對象，HTML中的<a>標簽（元素）實際上是實現了DOM Level 2 HTML的HTMLAnchorElement接口，再比如<div>標簽（分組元素）實現了HTMLDivElement接口。既然DOM Level 2 HTML和HTML 4.01關系緊密，那么可以存在：document.createElement(“div”)來創建DIV對象。可參考HTML 4.01規范來找尋其支持的元素。對于span這樣的分組元素在DOM Level 2 HTML中是實現了HTMLElement接口，與span一樣實現HTMLElement接口的元素是：
- 特殊: SUB,
SUP, SPAN, BDO
- 字體: TT, I,
B, U, S, STRIKE, BIG, SMALL
- 表達: EM,
STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ACRONYM, ABBR
- 列表: DD, DT
- NOFRAMES,
NOSCRIPT
- ADDRESS,
CENTER
這里面最特殊的DOM對象是document，它實現了HTMLDocument接口且沒有對應的HTML標簽，HTMLDocument是整個HTML層次的根并能處理HTML的所有內容。
除了內置與HTML對應的對象外，HTML DOM（瀏覽器）中還內置了JavaScript對象，他們是：Window、Navigator、Screen、History、Location，可閱讀HTML DOM 參考手冊，里面解釋得很清楚。需要說明的是：Window 對象表示一個瀏覽器窗口或一個框架。在客戶端 JavaScript 中，Window 對象是全局對象，所有的表達式都在當前的環境中計算。也就是說，要引用當前窗口根本不需要特殊的語法，可以把那個窗口的屬性作為全局變量來使用。例如，可以只寫 document，而不必寫 window.document，還有用得最多的alert()方法，也不用寫Window.alert()。
總結完畢。
請注意！引用、轉貼本文應注明原作者：Rosen Jiang 以及出處：
http://www.tkk7.com/rosen
]]>
]]>
]]>
]]>
最近一直在使用 Flex3 對原有項目進行重構和 bug 修改。遇到不少性能問題，分析發現由于 Flex 在和 Servlet 交互時使用了大量的 XML 作為傳輸格式，導致某些功能在處理 XML 時非常的慢，甚至還 Error #1502: A script has executed for longer than 15 seconds。讓人痛不欲生！
和 RIA Meeting 組織者 lwz7512 交流后，他建議使用 BlazeDS 來代替 XML 操作。隨著對 BlazeDS 的漸漸了解，的確能解決不少性能問題。Adobe 的 Flex 技術傳道士 James Ward 在 BlazeBench: Why you want AMF and BlazeDS一文中詳細比較了利用 BlazeDS 所帶來的性能提升，下圖是 James Ward 寫的性能測試工具。
通過上面的測試數據發現，正如 BlazeDS 官方網站所提到的：在使用 AMF3 作為傳輸協議后，Flex 和后臺交互的性能大約提高了10倍。面對這一結果，想必大家很興奮，看來是時候用 BlazeDS 來替換 XML 了。不過問題并不是這么容易就解決了，由于 BlazeDS 在 2007年12月12日才正式開源發布，而在這之前項目都是以 XML 作為傳輸格式（當然也沒用GraniteDS），并且 Flex 代碼中處處可見對 XML 的操作，要對這樣的代碼進行重構......難。
要解決 XML 處理的性能問題。就應該好好的利用 E4X，盡量避免在解析 XML 的過程中使用循環。這里介紹幾篇文章讓大家了解下《E4X：出色的 JavaScript》、《E4X 教程》、《AS3中新的XML處理方法 – E4X》。E4X給我最大的便利就是..運算符。思考下面的XML：
????????????????
<
groups?
name
="大組"
>
????????????????????
<
group?
name
="小牛組"
>
????????????????????????
<
person?
fullname
="rosenjiang"
/>
????????????????????????
<
person?
fullname
="abc"
/>
????????????????????
</
group
>
????????????????????
<
group?
name
="柴雞組"
>
????????????????????????
<
person?
fullname
="rosenjiang"
/>
????????????????????
</
group
>
????????????????????
<
group?
name
="柴鴨組"
>
????????????????????????
<
person?
fullname
="rosenjiang"
/>
????????????????????????
<
person?
fullname
="rosen?jiang"
/>
????????????????????
</
group
>
????????????????????
<
group?
name
="獨立大隊"
>
????????????????????????
<
person?
fullname
="rosenjiang"
/>
????????????????????
</
group
>
???????????????????
</
groups
>
;
要得到所有屬性fullname是”rosenjiang”的person節點的個數怎么做？在沒詳細了解 E4X 之前，我會用 myXML.group 操作得到 group 的 XMLList 集合，然后再用循環去找尋每個 group 中 person 節點屬性 fullname 為”rosenjiang”的數據：
???????????????????var?list:XMLList? = ?myXML.group;
???????????????????var?count: int ? = ? 0 ;
??????????????????? for (var?i: int = 0 ;?i < list.length();?i ++ ){
???????????????????????var?persons:XMLList? = ?list[i].person;
??????????????????????? if (persons.length()? == ? 1 ? && ?persons.@fullname? == ? " rosenjiang " ){
???????????????????????????count? ++ ;
???????????????????????} else {
??????????????????????????? for (var?j: int = 0 ;?j < persons.length();?j ++ ){
??????????????????????????????? if (persons[j].@fullname? == ? " rosenjiang " ){
???????????????????????????????????count? ++ ;
???????????????????????????????}
???????????????????????????}
???????????????????????}
???????????????????}
???????????????????Alert.show(count + " 個 " );
???????????????}
上面的寫法的確很傻，下面是改進之后的代碼，關鍵部分只有一行：
???????????????????var?list:XMLList? = ?myXML..person.(@fullname? == ? " rosenjiang " );
???????????????????Alert.show(list.length() + " 個 " );
???????????????}
通過合理使用 E4X 語法，順利的避免了循環帶來的性能問題。過了幾天，來個新的需求，需要統計出在這個 XML 中有幾個不同姓名的 person。思考片刻，我可不可以用眼睛數出來啊？這里有 3 個...... 好吧，看來又是循環問題，第一個想到的是用兩個嵌套 for 循環來進行排除處理，這是最直觀的想法......
下面我介紹下如何用 ArrayCollection 并只使用一個循環來計算個數。由于 Flex 里面不支持 Map 類型，而我 Google 了一圈，且 RIACN 論壇上網友的 Map 實現性能都不行，遂打算用 ArrayCollection 模擬 Map 進行操作：
???????????????function?on_click(): void {
???????????????????var?list:XMLList? = ?myXML..person;
???????????????????var?ac:ArrayCollection? = ? new ?ArrayCollection();
???????????????? for ?each?(var?item:XML?in?list){
????????????????????var?fullname:String? = ?item.@fullname;
???????????????????? if (ac.getItemIndex(fullname)? == ? - 1 ){
????????????????????????ac.addItem(fullname);
????????????????????}
????????????????}
???????????????????Alert.show(ac.length + " 個 " );
???????????????}
上面代碼沒什么過多解釋，思路是取出一個 fullname 放進 ArrayCollection，然后判定下一個 fullname 是否存在于 ArrayCollection 中，如果存在就跳過，不存在就放進去再取下一個。另外我發現，使用 for each 比單純的使用 for 性能要高一點點。
做了以上的努力后，性能還是低下！怎么辦？看來沒什么辦法了，和你的 boss 談談吧，考慮下進行大刀闊斧重構的可能性。或者能否在超時后給用戶一個提示，讓他操作的數據量少點，需要做的是捕獲超時異常，既 ScriptTimeoutError，請參閱http://www.cs.vu.nl/~eliens/pim/assets/flex3/langref/flash/errors/ScriptTimeoutError.html，進行 try catch 。 Good luck！
]]>
]]>
]]>
Flex簡介
Macromedia公司被公認為新興的RIA市場的領導者。今天98%的瀏覽器上都使用Macromedia Flash客戶端軟件，因此幾乎每個人都可以使用基于Flash的RIA。Macromedia Flex是Macromedia的新服務器產品，它使企業應用程序開發人員能夠全面訪問RIA的功能。Flex具有基于標準的架構，與當前企業開發人員的工具、方法和設計模式互補。
Flex應用程序與傳統的HTML應用程序的主要區別在于Flex應用程序處理最適合在客戶端運行，如字段校驗、數據格式、分類、過濾、工具提示、合成視頻、行為及效果等。Flex 可使開發人員更好地交付應用程序，這種應用程序使用戶可以迅速反應、在不同狀態與顯示間流暢過渡，并提供毫無中斷的連續的工作流。
Flex 應用程序框架
如上圖所示，Flex應用程序框架由MXML、ActionScript 2.0及Flex類庫構成。開發人員利用 MXML及ActionScript 2.0編寫Flex應用程序。利用MXML定義應用程序用戶界面元素，利用ActionScript 2.0定義客戶邏輯與程序控制。Flex類庫中包括Flex組件、管理器及行為等。利用基于Flex 組件的開發模型，開發人員可在程序中加入預建的組件、創建新組件或是將預建的組件加入復合組件中。
這里重點介紹一下MXML。與HTML一樣，都是標記語言，它描述了反映內容與功能的用戶界面。與HTML不同的是，MXML 可對表示層邏輯與用戶界面和服務器端數據綁定提供聲明抽象。MXML可將表示與業務邏輯的問題徹底分開，以實現最大程度地提高開發人員的生產率及應用程序的重復使用率。
Flex的不足
目前Macromedia最新推出了Flex 1.0 Updater，但它代號為“Brady”的IDE還沒有正式推出，目前還在進行Beta 3測試。拋開IDE不說，筆者認為Flex目前還很不成熟，還不利于在實際項目中使用。
例如，Flex自帶的ZipCodeValidator，里面只提供了美國和加拿大的郵編規則，沒有其他選擇，也無法個性化它?？磥碇挥凶约簛矶xValidator了，但這樣一來，和在JS中寫正則表達式有什么區別（代碼量和JS差不多）？用戶需要的是國際化的ZipCodeValidator，這樣才能提高工作效率。
一句話概括
現在的Flex才是1.0版本，很多地方都不完善，只好自定義才能完成特定的要求。期待著Brady以及Flex后續版本的推出！
RIA方案—基于JS的Bindows
Bindows簡介
“Bindows把JavaScript發揮到了第九層！”——網友這樣評價Bindows。
運行中的Bindows
的確如此，Erik等編寫這個框架已經將JavaScript的OOP和基于IE6的DHTML發揮到極點！Bindows 0.93發布的時候已經將IE內置的功能開發得淋漓盡致了，包括Filter、XMLHTTP、Web Service、VML。JavaScript用于客戶端界面的顯示和處理，XMLHTTP用于客戶端與服務器的信息傳輸。JavaScript在客戶端的表現力不容置疑，看看www.bindows.net所表示出來的能力，利用JavaScript幾乎可以實現Windows應用程序所能干的大部分事情，XMLHTTP一直以來常被用于實現“無刷新”的Web頁面，它和JavaScript配合，可以完成數據從服務器和客戶端的傳輸。
Bindows的不足
Erik喜歡那種一次全部載入的方式來實現腳本庫，使用過Bindows會發現，在窗口的加載期，需要一個漫長的等待過程，甚至瀏覽器的進程會產生無響應的情況。按照V0.93，腳本文件的大小是600多K，在一個普通的Web應用中，我們更多時候不會用到Bindows的全部功能，這點Bindows根本沒有遵循“用多少去多少”的準則。另外，過多的JS會使CPU占用率陡然增加，產生潛在問題。
內部大量利用了IE6的技術，沒有考慮到非微軟平臺的瀏覽器，限制了Bindows的流行。在圖表方面，大量采用了VML技術，在IE5，IE5.5這兩個版本，VML引擎不是那么的成熟，很多地方的顯示不夠流暢，會受到帶寬和硬件的限制，過分絢麗的圖形最終會給用戶帶來崩潰。“圖形方面我是采用VML的，當初太偏執，如果使用SVG來實現可能好許多的，也就是那段日子，我花了非常多的時間去折騰web方面開發。”——有網友這樣說。
一句話概括
在技術的角度上，從Bindows是可以學到不少東西的，但好像它的學術價值大于它的商業價值。
后 記
興奮歸興奮，冷靜下來仔細想想，運用RIA改造現有B/S模式還為時尚早。制約我們的首先是網絡環境和硬件環境的不完善性，我想沒有哪個用戶愿意花大量的時間來等待想要看見的“花哨”頁面，更不愿意等來的東西使自己的機器不堪重負，而換來的只是一些良好體驗吧？市場決定一切，而不是任何的新技術！其次，目前RIA的解決方案也不成熟，筆者看好Flex，可惜還需要長時間的等待才有結果。當然，還有很多RIA的方案，感覺MS的Smart Client + Web Service來頭不小。
本文叫“迎接RIA時代的來臨”，筆者充滿了對RIA的美好憧憬，期待著有一天能夠在RIA的環境中進行虛擬現實的交互式體驗！
鳴 謝：RIA中國 沒有他們，我想今天也不會對RIA有如此的認識?。。?BR>
參考文獻:
Flex 白皮書
IDC--RIA白皮書
回歸C/S?解釋Bindows
迎接Client/Server模式的回歸
Flex: RIA 的先驅，無堅不摧的銀彈？
Return of Rich Client
請注意！引用、轉貼本文應注明原作者：Rosen Jiang 以及出處：http://www.tkk7.com/rosen
]]>
看了幾篇關于“回歸C/S”的文章，作為一名多年開發B/S的程序員，不免熱血沸騰，深受鼓舞！曾經，我是B/S結構的忠實擁護者，同時也為了所謂的“零部署”陷入過技術泥潭。正當為B/S煩愁的時候，RIA走進了我的視線… …
什么是RIA
Internet已經日益成為應用程序開發的默認平臺。用戶對應用程序復雜性要求日增，但現在的Web應用程序對完成復雜應用方面卻始終跟不上步伐。用戶與今天中等復雜程度的Web應用程序交互時，其體驗并不能令人滿意。Web模型是基于頁面的模型，缺少客戶端智能機制。而且，它幾乎無法完成復雜的用戶交互（如傳統的C/S應用程序和桌面應用程序中的用戶交互）。這樣的技術使得Web應用程序難以使用，支持成本高，并且在很多方面無法發揮效應。
為了提高用戶體驗，出現了一種新類型的Internet應用程序。那就是Rich Internet Applications（RIA）。這些應用程序結合了桌面應用程序的反應快、交互性強的優點與Web應用程序的傳播范圍廣及容易傳播的特性。RIA簡化并改進了Web應用程序的用戶交互。這樣，用戶開發的應用程序可以提供更豐富、更具有交互性和響應性的用戶體驗。
基于主機模式→C/S模式→B/S模式→RIA模式
我們的行業經歷了幾次系統架構方面的重要轉變，在此過程中，客戶端的表現功能有起有落。上圖介紹了每個階段的計算功能所帶來的應用程序體驗方面的變化，這一過程從大型機開始，到RIA的出現為止。
隨著各企業組織認識到RIA模型可產生顯著的商業利潤、提高生產率及降低成本的優勢后，這種模型的發展勢頭越來越猛烈。這些應用程序結合了桌面應用程序的反應快、交互性強的優點與Web應用程序的傳播范圍廣及容易傳播的特性。系統架構發展的下一步是RIA，它最大程度地提高了廣泛性和豐富性。
論傳統B/S之不足
過程復雜性
過程復雜性是由于需要表達一個多步驟或多選項任務或互動作用所引起的。在HTML里，一個多步驟的任務可以在單頁內表達出來。但是由于HTML的互動性有限，便可能產生一份很長的頁面，使用戶感到混亂、笨拙而難以使用。為了避免這種難以忍受的用戶體驗，便需將任務在表面上看來“自然”的部分處區分成多個步驟，甚至需多個網頁共同完成。這種以網頁為主的用戶界面通常需要反復翻轉網頁，以解決在順序步驟中有牽連性的改變。其結果是緩慢、不自然、混亂而且令人感到懊惱的用戶體驗。
配置復雜性
許多Web應用程序允許用戶配置自己所要的定制產品——可以是皮包或是計算機，甚至是汽車等產品。但是配置產品是一項很困難的過程，因為在向用戶展示所有有效的產品選項組合時，應用程序必須能夠表達出有關的復雜性，尤其是當用戶可以從數十、數百或數千選項中定制出一個產品時。表達這些復雜性包括指出所需條件、有效和無效組合、一些導致問題的元素以及它們的適當解決方法；為每一項個人選擇提供費用信息以及費用總計（一旦有所更改）；還有最重要的是容許用戶觀看最后結果。這些是傳統Web應用程序相當難以表現的。
規模復雜性
今天，網站內的搜索工具大多是文本性質，間中夾著一些錦上添花的圖像。當用戶輸入他或她的數碼照相機準則，有可能是價格、以像素等，網站便接著回復數頁符合準則的產品，而大部分都是說明文本。反之，另一種方法則是使用視覺化來簡化搜索空間（也就是提供立即和動態的視覺反饋）。在一個視覺化選擇照相機的網站，其搜索過程可能如下：網站從一個包含所有照相機種類圖像的單屏幕開始。當用戶通過復選框、游標或數據輸入域來選擇篩選準則時，所有不符合準則的照相機圖像將被刪除，只余下符合準則的照相機可在屏幕上看到。因此，在把選擇聚焦至符合準則的數部照相機的過程中，用戶可經歷一個截然不同，而且和現實生活中的購物經驗更相似的體驗。
反饋復雜性
高度互動性的應用程序如游戲，能使反饋變得復雜，也即是指用戶行動和快速移動或情節不斷改變的屏幕元素之間的反饋環路。傳統的HTML頁面一向來都可以說是無法表達這類復雜性。它所需要的是擁有高度互動性和局部智能型的客戶端應用程序，以便可以在無需刷新全頁或干擾與服務器之間的通信的情況下，響應用戶的輸入和改變它們的狀態或界面。放棄如今依賴服務器的客戶機將使用戶體驗更吸引，同時也解決了反饋復雜性的問題。Web應用程序必須擁有表達復雜性的能力，以容許用戶視看復雜的數據、配置多選項的產品、搜索大型數據集以及容許用戶與數據之間的互動交換。
真正的RIA
為了解決如今的問題，理想中的Web應用程序應該能夠：
1、 利用無處不在的客戶機
2、 在多種硬件平臺上毫無更改的操作互聯網
3、 無論低或高帶寬的連接都可毫無妨礙的執行
4、 將處理能力復原給客戶（而不僅是提供能力而已）
5、 提供吸引人的高度互動的用戶界面
6、 表達過程、數據配置、規模和反饋復雜性
7、 無縫的利用聲音、視像、圖像和文本
8、 容許用戶在線和離線工作以支持移動工作流程
9、 容許客戶自行決定要在何時存取何種內容和數據（異步內容檢索）
10、 存取多種中間層服務（.NET或Java）和后端數據存儲
11、 采用新崛起的標準如XML和SOAP，為演進中的Web Service為主的網絡提供動態高效的前端應用
12、 與遺舊的應用程序和系統集成
13、 容許在現有Web應用程序和環境內逐步添加新功能以充分利用現有網絡應用投資
結 構
RIA本身有能力提供這類Web應用解決方案。如上圖，RIA將桌面型計算機軟件應用的最佳用戶界面功能性與Web應用程序的普遍采納和低成本部署以及互動多媒體通信的長處集于一體，終于成就了一種可以提供更直觀、響應性和有效的用戶體驗應用程序。它所具備的桌面型計算機長處包括了在確認和格式編排方面提供互動用戶界面；在無刷新頁面之下提供快捷的界面響應時間；提供通用的用戶界面特性如拖放式(drag and drop)以及在線和離線操作能力。Web網的長處如立即部署、跨越平臺可用性、采用逐步下載來檢索內容和數據、擁有雜志式布局的網頁以及充分利用被廣泛采納的互聯網標準。通信的長處則包括雙向互動聲音和圖像。
客戶機在RIA內的作用不僅是展示頁面，它可以在幕后與用戶請求異步地進行計算、遞送和檢索數據、重新畫出屏幕的一部分和密切綜合使用聲音和圖像，這一切都可以在不依靠客戶機連接的服務器或后端的情況下進行。
RIA提供一個強勁的技術平臺，使客戶機的能力復原到差不多與桌面型計算機軟件應用或傳統的C/S系統中的客戶機能力相似。它適合傳統的N層開發過程，同時也能夠和遺舊的環境集成以延展現有的應用程序而無需進行修改。它也可以作為基礎網絡服務的互動表現層，允許用戶在線和離線工作。RIA有能力解決各種復雜性，使需要復雜性的應用得以開發并且減少開發成本，同時在很多時候這類應用之所以能夠成形主要是拜RIA所賜。
請注意！引用、轉貼本文應注明原作者：Rosen Jiang 以及出處：http://www.tkk7.com/rosen
]]>
??? 利用 DWR，僅僅需要一個簡單的 jar 文件和向 web.xml 添加少量代碼來配置服務器端類。在 Web 頁面上添加一對 <script> 標簽，指明你所需要的導入的 Java 類，就可以馬上在 JavaScript 上調用 Java 代碼。更多詳細說明已放在 DWR 站點上。
JavaScript 的任務是通過 DWR servlet 來調用指定的 Java 代碼，動態創建 iframe。DWR servlet 的任務是配置一些參數，調用服務器端 Java 代碼為調用者向 iframe 提供返回數據。
譯者語
??? DWR 是個新東東，目前僅僅被認為是 alpha 版。在這一領域，據我了解還有 XML HTTP Request object（一般稱作XMLHttp） 和 XML-RPC。國內使用 XMLHttp 的很多，包括我前幾個月所參與的項目，實現了很多以前認為 B/S 很難辦到的需求，不過遇到的問題也不少，相同版本的 IE 有的卻要報錯，讓人很惱火。XML-RPC 國內用戶就少多了，我未接觸過 XML-RPC，在此不作過多評價。
在這樣一個日新月異的時代，希望 DWR 能經受住考驗！
請注意！引用、轉貼本文應注明原作者：Rosen Jiang 以及出處：http://www.tkk7.com/rosen
]]>
]]>