September, 2006 > 所有文章列表
＊常見問題解答
⊿每個 view (form)一執行時做那些事？
通常我們會在每個form 的開頭tag內加上 creationComplete=”init()”，等於是這支class 的進入點(類似java 中的 Main)，然後在 init()內跑 addListeners()將所有該偵聽的事件向 ModelLocator 註冊。
⊿那些變數是每個 form 都需要使用的？
一般來說 ModelLocator 與 DAO 是大部份 form 會用到的，因此通常我會在 form 的最前面宣告下面兩個變數：
public var model:ModelLocator = ModelLocator.getInstance();
private var daoContact:ContactProvider;
當然 dao 的物件就要依 form 的功能不同而改變，但 model 的部份幾乎是不會變的
⊿當一個form要與另一個form溝通時該如何做？
可透過 ModelLocator進行dispatchEvent() 與 addEventListener() 進行，這樣做的好處是任何需要偵聽這個事件的物件都可以自由的加入偵聽行列。
唯一要注意的是 addEventListener()要使用 weak reference才能確保不會發生 memory leak。
⊿如何在event內夾帶要傳送的資料？
可使用 Flex framework 內建的 DynamicEvent class, 這個 class 是 dynamic的，因此可在裏面加上任何的property，範例如下：
Var event:DyanmicEvent = new DynamicEvent(“MyEvent”);
Event.myData = [1,2,3];
Event.date = new Date();
ModelLocator.getInstance().dispatchEvent( event );
但使用 DynamicEvent 的缺點是沒有效率，因為class為動態而非 sealed，vm在執行時速度會較慢，同時開發時也不能享有 type checking 的好處，因此不建議使用。
另一個方法就是使用 CustomEvent class，請參考本範例中 event.CustomEvent class。在這個class中，我們定義了兩個prop，分別是 data 與 msg，其中 data 通常是用來存放要傳送的物件(array、xml或其它任何東西) 而 msg 則是附加的說明訊息，通常是純文字(string)
⊿view/form 應該要切割成多細才算適當？
這要看程式的功能與需求才能決定，也需要很多的經驗不斷重構才能有好結果。
但大原則是：合理 與 邏輯性。
合理是指功能相近或類似的ui就放在一個 form 內，例如電話簿為例，聯絡人列表與新增、刪除按鈕就應該畫分在同一個form內，但 edit 則不一定該屬於同一個 form。
邏輯性則是指form 的切割在將來是否能保有彈性，面對可能的重構(refactoring)與功能變動是否可在影響最小的情況下完成？form 與 form之間的相依性是否能降到最低？
初學者通常會對該切割出多細的form感到困擾，建議可多觀察 mac os x 的介面設計與佈局，尤其注意其版面內隱藏的區隔線或方格，那通常就是潛在的 form 人選。
⊿此approach 主要優點
-這是一個極度輕量化的開發手法，它沒有一定的規範與樣版，只是一群 design pattern與 best practice 的集合
-流程簡化同時層級也減少，加快開發速度
-概念簡單易學，只要掌握大方向即可快速上手
-class數量減少，將來編譯完成之 swf 體積也會變小
-彈性高，易維護
-適合中小型專案快速開發使用
⊿這個approach曾被用於開發多大的專案？
我們的team過去兩年來皆使用 riawave 進行專案開發，最大的案子大約有四十個form，總class約兩百多個，開發時間為半年，共三名工程師參與。
該專案為一飯店內部使用的電子看板系統，需同時俱備後台上稿系統與前台多媒體播放系統，其中後台系統部份需支援多國語系、role-based 認証與授權與複雜的播放條件設定。
這個專案的順利完成代表者 riawave 足以應付中型的企業級應用程式，並能在多人協同下共同開發，同時仍確保系統彈性與易除錯性。
⊿使用這個方法開發 Flex RIA 專案能確保成功嗎？
不，沒有辦法。
世界上沒有任何一種方法能神奇的確保開發過程一切順利，頂多只能籍由一個些經驗的累積與良好手法規範，協助工程師儘量少犯錯並在一開始就將事情做對。
同時，相同的開發手法在不同的人手裏，往往也會有不同的效果，這完全取決於工程師對整體系統規畫/設計的成熟度與經驗而定，因此不同的人用同一個方法看一個案子，可能就會得到不同的想法與手法，最終的結果也就完全看個人造化了。
⊿所以，riawave 真的沒有什麼缺點嗎？
當然不(但我們希望是)。
這也是我們公開此approach 的主要原因，我們希望籍由大量的同儕檢視，能協助共同發現可能存在的缺點，並希望能找出合宜的解決方式然後回饋給flex/flash社群。
因此，我們希望看過此份文件與範例的工程師們，能多多提供回饋意見，請不吝針對您發現的缺點與可改進之處提出建議，我們可共同討論並共商改進之道。
聯絡方式：jeremy@twmug.com
版權所有，請勿轉載或改寫本文任何部份，如需複製使用請取得書面同意授權
Riawave – pattern-based best practices for flex 2 development
All rights reserved, 2006 Richtechmedia.com
| by admin
＊riawave關鍵部份說明
◇Views – 主要的使用者介面
這支程式的設計手法是以 “component-based design” 為核心，畫面上所有的UI元件都合理的區分為不同的 logical unit，也就是 mxml component，或一般所稱的 views，通常它的命名傳統為 FormXXXX。
透過合理的 component 建構可享受的好處在於『彈性』，它又可以從下列幾個角度來看：
-相依性低:
form 彼此之間的相依性極低，彼此的交談，以及 form 與 dao間的交談都是透過事件廣播來達成，因此彼此的相依性降到最低，將來任何一個 form 變動(例如更改api或功能改變)都不會影響到系統中其它元件的運作，甚至也可以動態抽換其中的元件。
-版面變更容易：
由於 UI 版面配置不是採 water-fall 式的由上而下鋪陳在同一個mxml頁面裏，而是依功能性區隔在不同的mxml component(也就是 form)內，因此任何時候要變更版面設計，只要將 form 移往不同位置即可，例如原本 FormDetail是放在畫面的右邊，如果客戶要求將其改放在 pop-up window內，只要將 FormDetail 移到另一個 Panel 元件裏即完成。
-複用性高:
由於元件是按照其功能與屬性合理的切割，因此部份form 將來可重複使用，例如 Login, Register, ForgetPassword等，幾乎是每支web application都會需要的元件，這些部份只要製作一次，將來就可以將mxml直接複製到新project內使用。
◇VO – 傳遞資料時使用的物件
Value Object (又稱 Data Transfer Object, DTO)主要是用來在client 與 server間傳遞資料使用，透過 strict typing 可避免一般使用 plain object 時的問題，例如資料態錯誤等，同時也方便 client 與 server間自動mapping 物件，此點對於後台使用 java 的人更為重要。
目前大部份 remoting gateway 都提供自動mapping的服務，因此可能的情況下應該儘量使用 vo。
在 Riawave中，form<-> form 以及 form<->dao間的資料交換，一律都是以 vo 為基礎，同時存在 ModelLocator 中的物件與Array等，也都是vo。
◇DAO – 負責存取app server交換資料
Data Access Object 是專門用來存取 server端的物件，例如透過 remoting gateway 來回傳送資料到app server，並接收將server的回傳值。
這一層的用意是將client內所有需要存取server的動作都隔離開來，程式內所有的form 只操作 dao 這個物件，至於這個dao內部是透過何種方式與 server 溝通則沒有必要知道。
完全隔離的好處是將來如果要更換連線方式，例如原本使用 flash remoting, 但後來要換成 web service，只要在 dao內部修改即可，對程式中的其它form而言，只要 dao 的 public API沒變，則一切即可繼續運作無誤。
如果搭配 Spring Dependency Injection 的概念與 Class Factory 的手法，可在 runtime 透過 config xml 動態決定要使用何種方式與server連接，例如 http service, xml, web service 或 flash remoting。
Note: dao 在標準的 Java Pattern 中只是一個很小的部份，一般上一層還會有 Service Object，但此處為簡化範例，因此直接取用 DAO 名稱來代表這個概念。
◇ModelLocator – 廣播、儲存與singleton
ModelLocator主要的任務有三個：
一、 廣播中心：所有view、dao與其它物件要廣播時，統一都透過它的 dispatchEvent()執行；而所有需要知道(觀察)這個事件的物件，也統一透過它的 addEventListeners()來偵聽。
二、 儲存中心：所有程式執行階段要共用的變數，例如目前登入的使用者(user object)或系統設定值(system preference)甚至是datagrid裏目前選取的項目(selected item)都可以存在這裏；並且，這個class通常會設定為 [Bindable]，讓其它物件可透過 data binding 直接存取資料，例如 {ModelLocator.getInstance().user.name}。
三、 Singleton: 由於 ModelLocator裏的資料是整支程式所共用，因此它必需是 Singleton，如此所有的物件才能存取同一個 reference。
以實務上應用來說，最常見的用途就是：
-當一個form要跟另一個form溝通時(例如 FormA 要傳一個值給 FormB)，標準的做法是
FormA內：
ModelLocator.getInstance().dispatchEvent( new CustomEvent(“MyEvent”, dataObject));
FormB內：
ModelLocator.getInstance().addEventListener(“MyEvent”, onMyEvent);
Function onMyEvent( evt:CusomEvent ){
//handle the event
}
這樣做的好處有：
1、FormA 不會知道有 FormB 的存在，它只管拋出一個事件，內含要傳遞的資料
2、需要知道 MyEvent 的物件，自然會透過統一的廣播系統(ModelLocator)去偵聽這個事件然後處理，因此一個事件可以有許多個偵聽者，方便系統內不同部份協同處理
3、每個物件的封裝性不會被迫壞，不用像 ViewHelper一般必需要曝露元件內部的mehtod讓外界知道與操作，如此一來將來要重構元件或更改功能皆很方便，不用擔心會損壞其它部份。
而另一個讓 FormA 與 FormB 溝通的做法則是透過 binding，例子如下：
FormA:
例如在 FormA 內的 DataGrid 選取了一個物件，可以這樣寫
<mx:DataGrid id=”dg” change=”ModelLocator.getInstance().user = dg.selectedItem” />
也就是將目前 datagrid 選取的 item 存入 ModelLocator中。
FormB:
假設在 FormB中有一個 label 要顯示目前選取的user，可以這樣寫
<mx:Label text=”{ModelLocator.getInstance().user.name}” />
也就是使用 binding 將label 的 text property bind到 ModelLocator 的 user物件上。
這樣的做法跟第一種「事件廣播」法其實是一異曲同功，兩個form彼此之間是完全隔離而沒有相依性，只透過中間第三者(ModelLocator)轉手處理訊息，這也是目前 Cairngorm 2 裏面推崇的做法。
◇CustomEvent – 自製 Event 物件
Flex 2 / AS3 最大的特色之一就是全新的 Event Model，事件有特良好的循還廣播系統(dispatching and bubbling)，因此我們應該善用這個事件體系做為物件間彼此溝通的管道。
在flexsample內，我們使用了一個 CustomEvent物件，它的特色如下：
1、每個 custom event 都必需繼承自 flash.net.Event 或它的 sub-class
2、custom event 內應該使用 public static const (常數) 來標示事件的名稱，標準做法如下
public static const ADD_CONTACT:String = “addContact”
其中常數的名稱為全大寫(all capitals)，而後面的字串則採 camel case，第一個字母小寫，第二個之後大寫，這是 Adobe工程師撰寫 flex framework 時採用的標準 coding standard，也建議大家採用。
3、事件內有 data 與 msg 兩個 property，並且event 本身是 sealed class
Data 是用來放置要隨者 event 而廣播出去的資料，例如 vo 或 resultset
Msg 是放額外的資訊，通常是字串或 status message，這個可有可無
| by admin
咳，好，我知道這題目看起來很像論文，不過它跟學術一點關係都沒有，只是一個無聊想買 macbook 當開發機的工程師半夜不睡覺撐完全場live的感想。
為了要第一時間掌握這次event 的內容(其實是想知道會不會推出新款低熱量版 macbook)，事前我就找了幾個有 live text report 的網站，按照過去 WWDC的經驗，這些網站都會派記者現場將內容打成文字即時放送出來，所以只要定時refresh頁面就可以得知現場消息。
這次我鎖定了四個網站，分列如下：
-iLounge:
http://ilounge.com/chat/chat.php
這個最快速，即時，它透過一個 java applet 連上 IRC channel, 幾乎每隔五秒就會有新的訊息出現。(三句話不離本行，那個 applet 用 flex 重寫 loading 一定會更小跑起來更順user也會覺得更歡樂，至少能保証 firefox 也可用)
-Mac Rumors
http://www.macrumorslive.com/
它算是 text news 的 aggregator, 同時由 iLounge, Engadget, Mac Central 三個來源供稿，每60秒更新頁面一次，資訊比較豐富(因為集三家大成)，同時採用 ajax 製作理論上不用人工refresh頁面。
-Mac World
http://www.macworld.com/news/2006/09/12/showtime/index.php
macworld 是真人即時撰稿 ，大概每五分鐘網頁就會多一段新聞，這裏面最神奇的是記者文筆極佳，很難想像在五分鐘內要邊聽邊即時撰文寫出那種正式的文章，擺明就是事後不想再改，所以第一次就寫好，真的很讚吶。
-Engadget
http://www.engadget.com/
這是老牌3c消費性商品八卦站，當然不會錯過這種盛會，它們採取的是即時報導方式，圖文並茂，大概每十五分鐘出現一篇新文章，並且一定配上大張高解析度的圖片，同時文字內容也不差，算是四家裏面最拼的一個，雖然速度比較慢但滿足感最高。
所以，感想是什麼？
很多啊，光是這四種不同的播報方式就為”即時”這個字下了全新的定義，真的很難想像有一天我們可以透過這種方式，這麼多的選擇，這麼強的自主權，決定要如何取得資訊，同時每個人也擁有主動權決定是否要成為消息來源的一部份, we the media 真正實現？
這樣子的新聞傳遞恐怕連 SNG現場播報也很難比擬，不論是深度、廣度與觸及的閱聽人數量(那家的SNG畫面可以真的即時傳到世界每個角落？除非發生另一次 9/11)。
我想再過不久，應該就會有3g手機 live broadcasting，甚至可以先把手機訊號傳到server，然後透過 webcasting 播給一票人看，這些做法實在很有趣。
那看完後到底得到些什麼資訊？
嗯，其實也沒什麼，就是一些新款的 ipod，比較有趣的就是 ipod shuffle 變的很小，但容量只有1gb；真正值得注意的就是 iTV，一個小型的機上盒，可以透過無線網路傳送 video 到電視上看，不過我想中文世界大家最關心的就是：那我的 divx + srt 字幕能不能播啊？
所以結論是：bye bye macbook, 我們有緣再見囉~
| by admin
＊What is Riawave?
Riawave is a lightweight, rapid development approach specially designed for Flex 2, which takes many advantages of the Flex2’s new features, like data binding, event model, mxml component and view states, this ensures the quick development process and flexibility of the application.
Riawave is not a framework, but more like a combination of design-patterns and best-practices, it’s core spirit is Component-Based Design(CBD) and Decoupling, the goal is to speed up the development process and in the same time keep the maintainability and flexibility of the application for possible re-factoring or scaling in the future.
One of the advantage of Riawave is “easy to learn and easy of use”, almost every developer can learn it within a very short period of time( say 10 minutes ?) and never forget, more of, once you learned the core spirit of the approach, you can change it according to your project nature anytime without any problem.
* Download
source: zip or rar
online demo: try it
document(word format): download
There’s detailed explanation about the Riawave approach in the document, please do take a look at it.
＊Contact
The reasons behind writing this document and sample application to demonstrate our approach (named Riawave) is that we love flex 2 so much that we hope more developers can be benefited from a lightweight, faster and easier approach for everyday development, we would really love to hear from you, please feel free to drop us a line regarding any thoughts, bugs, modifications you think we should know, or simply leave a comment here, I will get back to you soon.
| by admin
＊使用者介面架構
-程式由下列 views 所組成
每個view 即是一個 mxml component
1、FormLogin
2、FormListing
3、FormDetail
其中 FormListing 與 FormDetail 被包在一個更大的 Container 裏，名稱為 FormMain。
這樣做的目地是因為整支程式分成兩個大的 State，一個是 Login另一個是 Main，它們的結構如下：
(state 結構)
-Login
FormLogin
-Main
FormMain
FormListing
FormDetail
程式一啟動時是顯示 Login state, 當login完成後即會切換到 Main state，為了在 Main state內維持程式的完整性，同時希望每個電話簿皆可以拖拉，因此多加了一層 FormMain(它是一個 Panel 元件，並加上拖拉功能) 去包住 FormListing與 FormDetail。
＊Flex project 目錄結構
專案目錄下有
dao
event
ui
util
vo
等五個folder(也就是package)分別置放不同類型之class 檔案。
一般大型專案建議採 com.companyname.dao 這樣的 package命名方式較易畫分眾多檔案。
＊基本流程
以「新增聯絡人」這個 use case 為例，它的操作流程如下：
1、使用者在左邊畫面按下 + 號
2、FormListing 透過 ModelLocator 廣播一個事件，名稱為 ADD_CONTACT
3、FormDetail 早先已跟 ModelLocator註冊偵聽此一事件，因此聽到 CONTACT事件後即執行 event handler，名稱為onAddContact()
4、onAddContact 會將目前表格中所有資料清空，並自動將focus設為為 name欄位以方便user輸入資料
5、當user填完所有欄位並按下 save 鈕時後，FormDetail即會生成一個名稱為Contact 的 Value Object(VO)，並將新輸入的資料放進此 vo 中
6、接者 FormListing 會操作 daoContact裏面的 addContact( vo ) 將此vo傳給 dao
7、dao會透過內部設定好的連線方式(此例中使用 flash remoting)將 vo 傳回 app server，並接收 app server傳回的值(由 _Result handler 處理)
8、Result handler 接到app server 回傳的結果後，即會做相關的處理(例如將server傳回的 array of object 轉換為 ArrayCollection of Contact VO)，然後將轉換好的 ArrayCollecction 存回 ModelLocator
9、由於 FormListing 中的 datagrid 早先是透過 dataBinding的方式直接結結到 ModelLocator 中的 currentContacts，因此當上一步中的 Result Handler 一將新的值存回
ModelLocator後，即會觸發 datagrid 更新畫面，剛才新增的 Contact 也就會出現了。
| by admin
Next Posts
Previous Posts
