本日必讀 - ActionScript 2.0 Best Practices

ActionScript 2.0 Best Practices (單頁方便列印版)

正在想如何重新改寫教材，現在問題解決一半了 Orz

只是現在才推這篇文章有沒有太慢了點，AS3 is right at the not so far corner…

RIA framework - Cairngorm 2 淺析

隨者 Itereation::Two被併入 Adobe 成為 Consulting Team與 Flex 2 /AS3 的面市，Cairngorm這個framework的正統性與普及性也跟者水漲船高，最近專為 Flex 2 量身打造的新版 Cairngorm v2 也剛放出來，所以早上花了點時間再 review一次，看看有沒有什麼大改變，本文就是一早研究心得的速記。

簡單來說，Cairngorm是一個framework，提供了許多現成的 class library、運作機制與template，目地是幫助工程師更有紀律的開發中、大型專案(by saying mid to large I mean 5-10 engineers in several teams and project time ranges from months to years)。

它的架構很單純，只有六大項

-business
-commands
-control
-model
-view
-vo

Cairngorm在最上層定義了六大塊的基礎結構，然後在每個 project 再 extends 後加入自已需要的功能，這也是大部份 framework 的玩法，例如 ARP, Struts, Cake等。

以 Cairngorm 2 內附的 login 例子來說，它的事件流程是這樣的：

1. 畫面上有 帳號、密碼兩個文字框與一個 login按鈕，當user按下 button時，form會將兩個文字欄位的內容打包成一個 LoginVO(Value Object)，然後將此事件廣播出去

2. 背景裏的 FrontController早先會先透過 addCommand()註冊偵聽這個事件，並且轉手將它交給 Command 處理

3. Command裏面只做兩件事，一是建立一個 delegate物件，透過它去連回server(細節請看下一步)，二是建立好 responder 物件，裏面有 onResult, onFault兩個 callback handler

4. delegate 則是真正跟 server連線傳接資料之所在(講的fancy一點就是它會連回 middle tier做資料交換與同步)，在這個物件裏面可以決定要用 remoting, web service, http get/post 等任何一種方式來傳遞，只要確定當結果回來時，要正確的 mapping回 responder裏面的 callback handler

5. 當 repsonder接到result後，就做後續的處理；在Cairngorm的設計裏，有一個叫做 ModelLocator 的 central storage，這個玩意基本上是個 Singleton Class，裏面放一堆程式執行期間要共用的變數與物件，以前大家都塞在 _global裏，後來 AS2時代我叫它 GlobalSettings (也有人叫它 SystemInfo)，總之意義都一樣，以這個例子來說，responder就會將接到的result更新到 ModelLocator裏面。

6、最特別的一點是在 ModelLocator被更新後，由於它裏面每個 member 都被設定為 binding，因此資料一改變，就會牽動所有bind到它身上的物件，例如 view的切換或 dataProvide的更新。

至此一個事件流程就跑完了。

這裏面比較有意思的地方有幾個：

-每個tier切割的很乾淨，甚至太乾淨了(你聽過水清則無魚吧？)，分工明確且單純，因此可以說是非常的 decoupling，對大型專案來說這是非常重要的。

-command 與 delegate 徹底分離，他的考量是這樣如果將來要從 Web Service 跳到 remoting甚至更炫一點的 Flex Enterprise Service時，只要換掉 delegate層就好，responder 的部份可維持不動。

-他善用 flex 2裏 event bubbling的特性，讓所有的事件都bubble到最上層的 Application後再集中做處理，只是這樣做的小麻煩就是一定要用自製的 event class去廣播才行。

簡單結論：

1、Cairngorm 是一個設計的想當不錯的framework，但實務上應用的機率實在不高，主要原因是他的優點也就是他的缺點。例如切割的太乾淨導致開發時間反而延長，對中小型的專案(五十萬以下二到三人合作)來說優點變成了負擔。

2、他有部份設計雖然乍看之下很 decoupling，但實作上卻會碰到難以避免的麻煩，例如 command 雖然設計美意是可重覆使用，但實際上每個案子的差異性卻會導致這種機率變的很低；另一個例子是 command 與 delegate分離，實務上當從 web service切換到 remoting時，如果傳回的資料結構與型態不同，勢必得將 callback handler重新寫過，所以一開始這樣的分離設計就是有問題的。

3、簡單講，想到每做一件事(例如 login)就要寫六個檔案(controller, command, delegate…)就覺得有點沒力，就算再自虐的 java工程師大概也不會想輕易嚐試，更別提如果這是在debug，光是trace到正確的檔案恐怕就得花六倍的時間。

正如古諺所云：Know the rules so you know what you are breaking.

知道有Cairngorm 這個東西還是挺不錯，至少知道那些地方可以吸收使用，那些地方可以再改良，更重要的是如果有一天真要上場處理超大型專案，至少也知道該從那裏下手使力(死道友不死貧道？）。

最後，做個小小民調：

你已經在使用 Flex 2 了嗎？(即使只是裝起來稍做把玩)
如果是，請留個言出個聲吧，真好奇在中港台三地已經有多少玩家們投入這個領域了。

下載網址

time to kick some arses…

文章

brief: it’s about time to explore flex 2, NOW.

===================

origin: Mike Rankin’s MX Blog

Monday, February 20, 2006

Flex - A Call to Arms

Inertia is a terrible thing in developers. There is nothing more depressing to me than walking into a cf shop and finding that they are still using CFStudio 5 with a single development server supporting the entire department. I usually find that this is an outfit that was unable to keep their visionary developers and now have a room full of grey cube drones, pounding away at uninspired code. No one in the department has ever been to Max or CFUnited, no one actually knows where the closest cfug is, few have actually read a blog, and no one actually has a copy of flash.

There is a lot of blame to go around when you find an organization like this. Part of the blame goes to the individual developers. They have been complacent enough to allow their curiosity and hunger for knowledge be driven out of them by the organization. Most of the time, the truly inspired have been frustrated to the point of finding a different position. Or worse; looked down upon by the organization as trouble-makers and malcontents.

A larger part of the blame goes to the lead developers and project managers. They are the ones that let their day-to-day responsibilities crowd out a spirit of innovation and discovery from their teams and departments. While the developers are responsible for the stagnation of themselves, these people are responsible for sucking the life out of groups of 5 or 10 people.

The largest part of the blame has to go to executive management for being out of touch with their core business processes. They are the ones that have failed to realize that by not exploring new technologies, they are ceding competitive advantage to the competition. They are the ones that have failed to recognize that changes in their companies initiatives have gone from sweeping technological breakthroughs to functional tweaks.

So, if you have suffered through this post to this point being insulted along the way, here is your official kick up the arse:

Official Kick Up The Arse

Developers: Download the Flex Beta now. Do it both at home and at work. If you are working in ColdFusion in any capacity today, you will be affected by Flex in some way. Get to know it now so it doesn’t trample you when it’s forced upon you. Exploring it is great fun. It brings back that “lightbulb” effect when you first get something to work the way it should. You will start to see where your upcoming projects could be made more engaging for the user and more fun to build for you.

While your at it, try downloading cfeclipse. Once you get it configured to the point where you can actually work on a file, uninstall CFStudio 5. If you are still using CFStudio5 a month from now, expect another big kick up the arse. The rest of us will all be pointing at you and laughing.

Project leads/managers: Take a risk. Set aside some time for your developers to look at Flex. Let them come up with a small project that they could build that could be used internally. Something that won’t break the bank but that could be made visible to other parts of your organization once it’s in place. You know there is always a list of small products your toolsmith wants built that never get paid any attention. Maybe there is something there you could put together.

Your developers will find lots of other uses for the technology as they build. KEEP A LIST! Take credit for spearheading the research activities.

CxOs: If it is important enough for your company to have a development team, then you realize how important it is to use it to make your company more competitive. If your teams spend 100% of their time working on maintenance projects or incremental improvements in existing software, then either 1) your development team is too small, 2) your middle management lacks vision, 3) you’re milking your Cash Cows (hey, that’s funny), but not building Stars in your quest for short term gains.

It’s time to kick your teams out of their rut. Spearhead a labs group. Make sure it has access to domain specialists across the organization. Devote at least an hour a month to stay in touch with the group. Make sure that the person you choose to lead your labs group reports directly to you regarding this part of their job. Provide the Labs manager with the authority to draw resources from the rest of your organization within reason. No one should spend more than 20% of their time on labs projects until you find a project that you decide should move into development.

Ok, that’s it for this kick up the arse. Feel free to post here if you want another ;).

(應網友要求原文轉貼，原文請參閱出處)

Flash RIA 的工作角色分配

今天去聽了一場Flash RIA養成班學生的作品發表會，突然又想到了這個塵封已久的題目，就趁還記得寫下來。

用 flash 做 RIA專案是一件很 tricky的事件，一來是因為它還太新，缺少共通且廣泛的典範可依循，二來則是這這個工具(flash, actionscript)本身不是很利於開發程式導向的專案，而大部份所謂的 RIA 都是 visual-and-code-intensive, 在前端同時需要龐大的視覺設計與程式碼才能完成。

因此經過幾年發展 ，大部份人都應該已經體認到在今日要推展一個成功的 RIA專案，團隊裏至少需要下列三種角色：

1、flash designer: 純視覺系的設計高手，懂色彩、比例、線條與一切的美術設計技巧，但可以是個程式生手。

2、flash coder:專做前端的flash actionscript 設計，將設計師做出來的 fla 套上程式碼，賦與互動與生命。

3、server coder: 專責處理 server 端的一切事務，不論是用 jsp/php/.net/cf 與 sql/mysql/oracle任何一種db。

這三個角色的區分有其必然的因素，但麻煩的地方在於這三個角色也不全然能一切劃開從此相安無事。

以我個人幾年來從事專案製作的經驗中，體認到最麻煩的一段就在 flash coder身上，這個角色的人向前必需處理設計師的fla，將一個個的mc與動畫套上程式碼，而向後則需要與 server side溝通(這裏面又包含了必需靈活的使用各種介接技術，例如 get/post, web service, xml, remoting…)。

第二麻煩的就是 flash designer這個角色，以往的設計師工作內容很明確，就是搞定視覺的一切細節就好，做出美美的畫面一切就不會錯；但當 flash 不再只是動畫的呈現，而成為一種操作介面或應用程式時，設計師的工作界線就開始模糊了，因為設計師得開始小心的考量 usability, navigation system等各種因素，同時也要瞭解 flash 的 do and don’t，三不五時還會被期待能順便寫點程式，最好能一手包辦留言版、討論區….

這時最常見到的情況就是：老闆問設計師，為什麼 converse site 的效果你做不出來？設計師只能啞巴吃黃蓮的說：flash可以做的東西很廣，converse 那種視覺介面跟動畫我會做沒錯，但它後面的程式我不會寫啊~
然後老闆會再回一句：啊你不是說會用 flash….

然後老闆去外面找一個工程師進來上班，工程師花了幾天時間看了一下actionscript 就開懷大笑的宣佈：這玩意跟 javascript/.net一樣 ，沒問題的啦~

等到設計師把fla 丟給它請他開始coding生出 converse site時，工程師才發現奇怪怎麼 DOM不太一樣，我的 include去那裏了？

這是一個很久前發生的真實故事，但實際上同樣的問題到今天仍然存在。

這裏的重點實際上只有一個，就是上面所提的三個角色其實都不好當，各有各的難處與know how，但一個成功的專案又需要這三者同時發揮最大效力才能成功。

但很可惜的是，目前似乎許多人(不論是新手或老手)還沒有體認到這點，而想三者兼顧成為全能型的超人，當然這或許是商業環境逼迫使然(老闆們總是希望花一份薪水請到能做三件事，最好還能三十分鐘弄一桌好菜的員工)，也可能是人心必然貪婪的結果，大家都朝「廣」的那個方向前進，而沒有找一個既定的領域去深入。

就像一個朋友最近跟我說的：他在看resume時，專長一欄寫越多的，錄取機率就越小。

(btw, 通常超過一頁的resume我也是直接略過，或自傳的開頭是「我生在一個小康的家庭」也比照辦理)

畢竟大家都是過來人，知道要 master一項技術需要多長的時間去養成，如果一個二十五歲的年青人可以寫上十來項「專長」，那背後的意義就不言可喻了。

今天在發表會上看了四到五個用 flash 做的 ria專案，其中大部份是購物車範例，看完後一則以喜一則以憂，喜的是就跟幾年前在資策會教出第一班ria學生看到作品時的感覺一樣，覺得很高興有一群學生會用flash做程式整合類的作品。

但憂的則是今天看到的作品水準跟過去幾年看到水平實際上差不多，當然學生們是初學新手，忙者在消化記憶新知識與技術之餘，手忙腳亂的做出作品是不能跟商業專案相比，但在作品中一貫的缺乏 usability-design 意識則是讓人較為憂心的部份，類似這樣的flash作品往往就是外界攻擊的主要所在，畢竟畫面做的美不美或功能強不強是其次，一個簡單乾淨易用的操作介面是所有設計最基本的重點，這點不能因為是用flash就有所改變(理論上，反而應該要更好才對不是嗎？)

從這點出發，讓我開始重新思考或許下一次開始，應該要降低課程的難度，簡化範例的內容，但至少有機會完整的示範一個兼具功能性與易用性的例子，這樣或許會比較教太難太深的例子對學生更有幫助？

flash 8 自製 modal window

範例下載

在flash 裏要產生 modal window(只有前景的視窗可操作，背景所有東西都不能按)有兩種方式，一種是用 PopUpManager，另一種是用 Alert.create()。

一般正常用法是先透過 PopUpManager 產生一個 Window 元件，然後再用 Window.contentPath = xxx 將自已的東西放進去。

但這個做法有個缺點，如果你不想要那個固定格式(灰底 + titlebar)的視窗，就要很辛苦的動點手腳重新 skinning。

最近有個案子又需要這種功能，但設計師(hi Brad!)需要用自已的mc視窗，因此我寫了個小工具可以隨意指定自製的mc 成為 modal window, 原理其實很簡單，就是把 mx.managers.PopUpManager 打開讀完一遍懂了後就知道，讀完後就會知道其實 adobe 的工程師已經寫好許多方便的小程式等者被用，例如

1. DepthManager 裏面有 setDepthBelow(), createChildAtDepth()等程式可用
2. 這些 Manager都會隨者 Window 元件一起以 mixins 的方式加MovieClip身上。

如果你沒時間再走一遍整個流程，看看這個超短簡介也可以，基本上產生一個modal window的過程如下：

1、先產生一片超大的白色mc把整個畫面(Stage size)蓋住，然後在它身上吃掉所有的 mouse click event。

2、用 setDepthBelow() 將剛才產生的白底mc 移到 自製mc 的下方，這支程式會很聰明的將 自製mc 移到剛才 白色mc的上一層。

至於關掉也很簡單