Ruby On Rails 已經紅一陣子，flex on Rails 也已經被提起過很多次，現在終於有熱血青年出來實作這件事了，而且還是用 flexstore 為範例。
非常可惜的是，這篇文章跟實作讓人失望了。
我理想中的 Flex on Rails 並不是這樣搞的，而是應該汲取 RoR 的精神跟優點後，改寫整合進 flex framework，就像當初我們用 Cairngorm 與 ARP 改出比較符合本地小規模專案使用的 framework一般。
不過老實說目前使用的方法與框架感覺上已經非常有效率跟順手，根據永遠不變的準則：
if it’s not broken, don’t fix it
還是一動不如一靜，多花點心思在來寫 flex framework 與 component sets 比較實在啊~
這本書的作者 samyoyo 與 belinda 姐妹是我認識多年的朋友，二十歲出頭第一次前往美國前曾請教她們不少相關安全經驗跟旅遊景點，經過這麼多年後她們仍然熱愛遊行四處啪啪走，以她們姐妹倆藝高膽大的性格加上姐姐多年文藝(資深 ? orz )美少女的細緻筆觸，寫出的深度旅遊書絕對值得一看。
有興趣的朋友可以去看看。
咳，那這篇文章跟本站 RIA 主題有何關係呢？嘿嘿，今年十月去 vegas 參加 max 2006 時有個最佳響導人選啦~想住便宜大碗的豪華飯店外加免費食物與交通，找這對姐妹花就沒錯…
flex framework 是一個十分精細與複雜的架構，在輕鬆將元件(controls / containers) 拖拉到畫面上就能構成一個 appliction ui的背後，其實是這個 framework 在暗地裏提供了許多底層的服務，才能讓整個flex 應用程式順利啟動與執行。
上面這張圖是從比較高的位置來鳥瞰一支 flex app時所看到的架構。
簡單的說明如下：
＊每當開啟一支 flex app swf 時，最先被載入並執行的並不是程式(controls/containers)，而是 SystemManager，它有點像是作業系統中的 Boot Loader，Loader載入後才能 bootstrap 後面的每一道手續起來。
＊當 SystemManager 載入並啟動後，最先顯示在畫面上的就是 Preloader，也就是灰色的 progress bar，這是因為此時 SystemManager 正在下載其它需要的元件與 class library。
＊等程式所需的 class library都下載完成後，progress bar 就功成身退，此時SystemManager 就會建立 Application 元件。
＊Application元件是整支 app的最底層，至少所有 UI 面的元件(例如 panel, button, chart…)都置於這個 Application元件中，所以說的更明白一點就是：在flex中，所有東西都是元件，一層包一層，而往上trace到最根本就是這個 Application元件。
＊同一時間，SystemManager 也會建立 Cursor Manager負責管理各種 cursor，例如顯示 arrow、hand等不同的圖示，當然如果你想隱藏滑鼠游標，也可以由這裏下手。
＊Drag Manager則是專門負責各種拖拉行為，例如 flexstore裏面把商品拖放到購物車裏，就是靠 Drag Manager去啟始拖拉，並置換 Drag Proxy圖案，然後偵測滑鼠的位置來顯示不同的鼠標(例如綠色的勾勾，紅色的叉叉)
＊PopUp Manager 是處理各種需要跳到最上層視窗的地方，例如 Alert window, 或 TitleWindow等需要置於最上層的元件，就是靠 PopUpManager.createPop()去建立，同時它也可以提供 modal window的服務，也就是在 window下方產生一大片白色吃掉所有的滑鼠反應，這部份的 code base 基本上跟 flash 8裏面沒有太大不同，這篇裏有相關介紹，唯一的差別是由於 flash 8 的 Bitmap API提供了 catchAsBitmap指令因此可以順便加些 blur/dissolve效果上去。
＊ToolTip Manager 則是負責顯示所有的提示文字，它的實作也很簡單，當滑鼠 rollover 任何一個物件時，framework會去探詢該物件是否有 obj.tooltip=”xxx” 這樣的屬性，如果有，就交給 ToolTip manager去畫一個黃色背景的框框將文字顯示出來，並且在一定時間後 fade out。
上面介紹的這六個東西就是一般在撰寫 flex 2 application 時工程師最需要瞭解的基本的結構，一旦熟悉這個架構後，就可以解釋許多疑問，例如：
Q:為什麼 Cairngorm 裏面的 CairngormEvent 從 TitleWindow發出後，無法像其它地方一樣向上 bubbling 到 Application 然後被 controller 接收？
A:因為 TitleWindow 是透過 PopUpManager 直接建立並附加到 SystemManager身上，因此 CairngormEvent 向上 bubbling 後最終落點是在 SystemManager而非 Application，因此收不到。那解決方法為何？請大家想想吧。
Q:如果我想做 ShortCut Manager，能偵聽並處理所有的 shortcut key該如何下手？
A:從這個架構圖來看，可能的下手地方有三個，第一是在 SystemManager裏面偵聽所有的 keyDown event然後做解析；第二是在 Application 裏面偵聽並處理，第三則是直接操作 flash.display.InteractiveObject 這個class去處理所有的 key event。
其它諸如此類比較牽涉到 low-level system architecture的問題還有很多，但只要先徹底瞭解 flex 2 framework 的架構與運作原理，許多問題就會自然解決了 
這真是個好問題，我也經常被問到或被要求評估一個系統、專案、程式的規模有多大。
但要如何評估一個系統的大小呢？看檔案數量？看檔案體積？看程式碼行數？
這篇文章說明了他們使用的方法，但我覺得並不是很精準，但也可能是因為他們是在fuseaction framework的架構下決定用那些條件去計算。
通常我的計算方式是看 screen 數量，其次是看 dao 與 backend service的 public method。
screen數量指的是一個程式用到的畫面有多少，例如 login 算一個 screen, forget password 算一個screen，而主要操作畫面裏每個 tab 下面的mxml component也算一個獨立的 screen，從這樣的單位來計算有兩個好處：
1、可以明確的知道工作範圍，而且是一個可以量化的單位，例如這個案子有四十個screen，就大概可以估出要多少時間才能寫完。
2、可以借此抓出大概的預算，因為知道screen 與 dao 數量後，大概就可以知道整個專案要寫的程式有多少，需要幾個人分工，每個人可能要多少時間，把這些單位加加減減再乘上一個權數與安全系數，就可以得出報價了。
至於 dao指的是前端存取後端的 methods 與後端 app server / beans 裏面提供的服務，這部份通常很routine 重覆性也很高，但如果遇到一個沒寫過的功能，就會特別小心，要把安全時間拉長預算也提高。
因此通常被問到「專案有多大」這個問題時，我給的答案都是類似：50個screen、4個人、二兩個月之類的數字，這個方法經過這兩年的不斷失誤與修正後，現在準確度大概有75%左右 
你有什麼特別的估算方法嗎？
這真是一篇有趣的文章，關於何時該用 singleton 與 static 的問題我也已經想很久。
早期我習慣用 Static class 做為中央儲存地(dump site ?)，例如把utility methods, prop, constant 都塞在裏面，這樣方便存取。
但在 flex 2 早期的幾個版本裏，static class無法透過 binding 整合到 view去，再加上 Cairngorm 2 出來後 ModelLocator 一律採用 singleton設計，那時究其原因也是為了解決 static prop/method 無法 binding 的問題。
正當我們想全面轉換成 singleton時，flex 2 beta 2 出來了，adobe 很勤快的解決了 static prop binding issue，所以之前的老方法又可以繼續使用。
這下子就陷入兩難，需要在兩者間做點選擇：到底該繼續用 static class就好？或是follow Cairngorm 的 singleton ? 當然後來我們已經有了答案，但先來看看這篇文章講了什麼。
這篇文章的基本要意就是： singleton 的彈性比較大，在可能的情況下應該儘量用 singleton而非 static.
主要的 rationale 如下：
1、singleton 的彈性來自於它可兼俱 Factory 的性質，例如 getInstance()也可視為一個 factory method 動態的產生物件(甚至是傳回一個 Abstract Factory)，然後透過『多型』就可以輕鬆的置換許多 method 的功能，彈性與威力無窮。
2、singleton class 可以 extends 與 implement 其它class，但 static class 不行。
3、singleton 是 statefull，如果需要維持 state，用 singleton會比較方便。
另外，文章中也說明了選擇時的判斷條件：
1、如果是靜態不會改變的東西，例如 String utility (parse, sprintf…) 就很適合放在 static class裏，而此時它的用途就跟以前的 _global 沒太大差別，這也是colin moock 在 EAS2 中建議的方法。
2、如果是未來可能會改變的東西，放 singleton class會比較好，因為統一透過 getInstance()取得 reference後的操作行為都是一樣的，因此將來business logic 要改只要在 getInstance()動手腳傳回相容的介面即可。
這兩點也是我們後來選擇 singleton 時主要的依據，用到現在覺得還挺方便，沒有什麼大問題。
