The Rules of AJAX Web Application Design - Part 1

Because I'm a Taiwanese, So I'll try to keep my blog in two languages, English and Chinese.

After more two years working in ZK, I think I'm quite good at how to design an Web Application based on Java technology,  although I'm still not familiar with Javascript, He~ He~.

Using ZK to build a Website is very simple, you write a XUL-like xml file(with extension .zul) to describe page structure, then you add event-listening method in controller, sub-class java file or even in zul file as some kind of sever-side script. finally, Inside event-listening methid you operate widgets and trigger business logics do make something really happen.

But, it's simple doesn't means it's easy, to build an AJAX Web Application would never be easy if you don't have enough knowledge and experience of the differences from plan-old HTML.

About knowledge I GOT NOTHING to say, you JUST NEED TO KNOW the very detail of Markup Language, browser, HTTP, app server and the programming language that you choose. ZK in here is YET ANOTHER AJAX FRAMEWORK, so it won't help you to make them easy, nor GWT or JQuery. All of them will torturing and fool you around before you have solid base knowledge.

Role No 1: 1024 * 768 No longer to be the limitation.

In traditional page based dynamic web programming(like ASP, PHP, JSP), the most popular resolution that user had in there screen had limited(not complete yet...)



算是把這兩年來一些做開發的心得給整理一下吧？
可能的話，打算給個三部曲之類的東西。


心得一： 1024 * 768 不再是網頁大小的限制。
傳統的Page Base網頁，螢幕解析度是多少頁面元素就是多少，跟堆積木一樣，1024 * 758 的畫面就是塞不下面積和超過的元素。
但是在AJAX網頁裡面，透過動態Layout元件(layout, tree, group, listbox)的幫忙，畫面可以被Flip, Swap, Collapse, popup, 我們在單一頁面空間裡能塞進的元素、功能都爆增了。

• 透過 Collapsible，我們可以在需要的時候滑出特定Panel呈現功能介面。
• 透過頁籤，我們可以將多個Tab疊在同一個Panel裡，每個Tab放各自的東西。
• 透過Tree，具有Hierarchy特性的DataModel可以不佔空間的呈現其結構。
• 透過popup，我們可以隨時使用一個佔據整個畫面中間的Dialog呈現非特定的操作介面與訊息。

簡單的說，網頁從2D 變成了2.5D。


心得二：Browser Request's Response的資訊量管理比以往都更加重要。

在Page Base的時候，一個頁面能夠呈現的資訊量有限，而網站不同的操作介面會透過Hyperlinking切割到其他的Response的結果裡，所以單一Response裡server需要初始化的項目不多、一個畫面需要載入的元素也不多。

但是切到AJAX這個2.5D概念的世界之後：

1. 更多的Business Object, Service initialization需要被執行。
2. AJAX元件的overhead一定比陽春的HTML高。
   

想像一下一個有著超過15個Tab的頁簽，平均每個Tab需要啟動一個Service、包含 200個 Components的AJAX 網頁(也許是做ERP系統)，沒有使用任何Lazy-loading的技巧，也不透過Hyperlinking做切割，這個單一Response的資訊量會是驚人的。

期待一個Response要Provide的資訊量有多大，那麼Server-side要執行的運算量就有多大、

一個AJAX網頁做的越複雜，Browser的運算負擔也越增加。

(不要忘記HTTP就是HTTP，HTML就是HTML，而該死的IE6全球還是有超過40%的用戶。)

當Browser Request's Response的資訊量開始產生Responsiveness的問題時，如何在可接受的範圍內不損及Usability 將這個資訊量切割到不同的Response裡，就是開發者的責任。
客戶用的瀏覽器越爛、網路越慢、server等級越差，就越考較開發者架構設計上的資訊量管理能力。
以下是一些常見的技巧：

• Lazy-loading：將特定區塊的UI 元素以AJAX Request延遲載入到畫面上，這可以降低Browser Request latency。
  
• Paging：對於Collection Component的呈現筆數進行限制是必須的，想要一次把10000個AJAX Component load到頁面上並不聰明。
• Hyperlinking：不要AJAX過頭，有些開發者一開始AJAX之後就覺得用Hyperlink有罪惡感。HTML就是HTML，Hyperlink在阻隔不當操作、區分狀態、降低單一頁面Controller的複雜度、支援SEO是非常管用的。
• Remove Unused Elements: 元素加得上去也可以拔得掉，可能已經不用的AJAX元素可不可以先拔掉，以後要用到再接回來呢？ 

開放原始碼是很重要的

之前在網路上與別人討論關於開發平台的選擇時。
聽到有一派的人他們的說法是：
『絕大部份的使用者並不會在意是不是 Open Source，
甚至連是用什麼語言寫的都無所謂， 終究對於使用者來說，好用才是最重要的。』
這段話衍生的意思似乎是：
『所以開發者也不應該在意是不是 Open Source，一切以實用為觀點就好。』
個人認為，使用者就短期而言可能不該在意，但是開發者以如此態度面對這個問題卻是不應該。
就算是對使用者，『好不好用』很重要的沒錯，但也並不是唯一重要的。 人們追求『可計算的好用』時，得要損失多少他們不去計算的附加價值與機會成本呢？ 而這些東西可以說就是一個專業開發者所應該為客戶思考的。
而單就『最好用』來說，目前的通用開發平台以長期智慧投資而言，開放平台具有私有平台有更好的競爭優勢。
我們考慮幾個事實： 
最有效率、最能高度客制化的作業系統、Http Server不是私有的。 功能最強、最快的通用網路UI平台(Browser)不是私有的。 最前沿、最有價值的商業模式創新，早就離開了私有的平台。 就連手機這種容易被綁標的系統，開源的平台也逐漸的拓展進來了。 
目前大概只有具有悠久歷史、功能成熟的單機大型應用軟體還是私有的比較好用。 況且，開放原始碼最大的重要性在於創造新的社會價值、規範體系，為即將到來的知識經濟社會結構建立基礎。而不只是它很多人參與、很強大、可以踢像Microsoft這種公司一腳而已。
勞工離開了資本，起碼還留有技能去下一個資本家那裡繼續生產。

可是知識工作者從前人習得了許多智慧，終於要開花結果的時候，其成果卻有可能要為私人所獨占，不能再成為他人思考的基礎。甚至發表相關論文、談話言論的權利都有被剝奪的可能。

我不認為這是一個基於民主價值規範體系的社會所樂見的。

舉例來說：

如果有人寫出，基於XXX演算法所能寫出來最有效率的程式碼。那是不是從此以後這個人離開了公司，就再也不能去寫相關演算法的程式，也不可以在Blog上討論這門技術的相關細節，不然就要面對前公司提告的風險呢？如果這樣，是否知識經濟的社會將比工業經濟的社會帶來更大的不平等、更多的壟斷？

今天我在公司寫程式，難道明天我出去其他地方，同樣的知識概念就要被禁用嗎？

我為了公司的需求寫程式，並不見得代表我從此以後就得把我運用知識的權利賣給公司。
話說回來，對一個法人而言，如果知識財產的保障過於薄弱，公司的獲利基礎又該建立在什麼樣的方面？ 組織創造、創新的報償又要如何實現？
以消極面而言，到底是誰侵害誰，是員工瓢竊公司財產，還是公司剝奪員工、社會使用智慧的權利，誰該禁止、如何懲處，孰輕孰重實在難以釐清。
到底，軟體智財所要保障的財產權對象該是誰？是個人、軟體公司、還是社會？
我相信，在這裡，開放原始碼運動提供了一種新的遊戲規則。

開發者與軟體公司之間透過對於軟體產品賦予由公認第三方所建立的開放原始碼授權，即建立了一社會契約，在這契約中公司獲得主導開發方向的權利，並得益於內外部開發者的產出、社會獲得智慧的流通與再利用、開發者透過身為社會的一份子，獲得延續個人智慧產出的權利。

在這種模式下，軟體公司不再能透過授權獲得大量利益。但仍然可以透過客戶服務、系統應用服務來獲取利潤，同時若能建立起基於新的商業模式的軟體應用服務，賺取鉅額報酬的可能性仍然存在。

開發ZK Forum的心得感想

這兩個月以來跟Junior一起把ZK Forum重新寫過。

收穫是：

1. 果然有很多東西得要實際用下去才知道怎麼回答。
如果只拿ZK 寫教學、Consulting用的還是測試用的程式，是不會發覺這些問題的。
公司如果要增強Consulting的實力，打通客戶從採用到開發完成的門檻，減少ZK在實際開發應用上的一些問題(例如:Serialization, Clustering)做專案確實是很必要的，就算自己不做，最好也要有廠商可以長期合作才行。

2. 公司內部的知識分享交流效率很重要。
這次帶了三個Junior來寫，其實自己主要的工作變成是在訓練他們，而不是開發軟體。
感受最深刻的是，跟他們綁在一起用同一台電腦工作後，才發覺一些自己覺得理所當然的東西其實並不是大家都知道的。Junior們最大的問題就是還不能清晰的在頭腦裡建立起模型，這使得他們在思考解決方案時，常常會選副作用很大的快速解。
在這樣的團隊組成下，知識、訊息的分享交流變成最主要的任務，一個人犯的錯要可以變成大家的經驗。而程式碼Code Review的比例提高則是無可避免的。以這次專案來說，幾乎要達到60%才行。


3. 比起單純的懂得ZK，我們更需要熟悉其他Java世界的知識。
我們需要很多其他知識: 例如Hibernate, Spring, JBoss Seam, Tomcat 調校...
這個專案讓我發覺自己在這一塊是缺乏的，還不夠好。一些設計上的錯誤花了我相當多的時間去重新調整。從Consulting Service的角度來看，客戶常常需要的是一個package而不是單純的ZK ，只講ZK大部分的客戶是不知道怎麼介接其他世界的。

4. 我們需要界定list出許多常見議題，並建立Best Practice。
沒有人有耐心，大家都希望清楚明確的答案可以彈指獲得，想像得到要考慮的議題都已經有人深入思考過。開發一個需要實際Production上線運轉的系統這些問題才問得出來，能夠先客戶一步去思考。

5. 專案管理能力有待加強。
特別是時程，還有規模。要訂定一個2個月時程大小的系統開發時程，我的能力還相當不足且不穩定。