推 gpmm:原來如此，受益良多啊 XD 09/12 00:37
推 adxis:C++ Wt lib 09/13 00:19
話題拉的有點遠了，換標題繼續討論吧 XD
※ 引述《gpmm (銀色)》之銘言：
: ※ 引述《TonyQ (沉默是金。)》之銘言：
: : 但是相對的也會需要去面對 ajax 真正麻煩的那一部份，
: : 那就是你到底需要做什麼，還有你的畫面應該在每個ajax狀態呈現些什麼。:-)
: 終於有時間回了，
: 我換個方式解釋，T 大聽看看對不對，
: 原本一般的架構設計是
: 前端：介面 | 定義的介面邏輯與介面反饋 | 發送請求（資料）
: 後端：接收請求（資料）| 資料的邏輯處理與請求反饋
: T 大您現在的架構是
: 前端：介面 | 發送請求（資料）
: 後端：接收請求（資料）| 處理介面邏輯 + 資料邏輯 | 反饋介面命令 + 資料
: 換句話說，每一個行為的處理統統都交由 server 來做決定，
: 試著舉個例子，一個計有五列的表格，每列都有一個 checkbox，
: 當使用者 click 時，瀏覽器直接將此 ui request 送給 server 來回應，
: 於是 server 可以依據不同的情況（例如 user 的權限足夠與否）
: 來進行不同的介面回應（於是整列選取並變色，或彈出視窗告訴你無法點選）
原則上是你這樣說的沒錯，不過實際上其實還有很多可以延伸討論的空間。
（後敘）
: 但是這樣的好處是什麼呢？ ui 具有動態調節的空間嗎？
: 依據這種設計結構，的確 defer 和 muti-ui-command 的結合送出變的非常重要了
: 很好奇 T 大是開發什麼樣的網站或著服務或有這麼特別的架構？
: 聽起來都是在嘗試使用比較特別的技術，好羨慕…ˊˋ
server centric 的優點主要在於幾點
1.資料的隱密性跟資料邏輯的隱藏，這對安全性來講是有加分的。
2.使用者無須自行撰寫 js code 就能進行最基本的事件處理。
（這個應該是最有吸引力的部份。XD）
3.因為使用者並不是寫實際的html ，
所以 ui 比較有機會 port 到別的平台上。
4.比較容易對 js /css 做最佳化。
講優點當然不能不講缺點
1.因為是 server centric ，勢必要有資料的載體，
過去這些資料都是在前端，而為了作到前後端同步，
所以會有一些資料都是綁在 session 上，記憶體上負擔會比較重。
2.流量(traffic) 的部份，需要花很多時間跟心力去作最佳化。
所以才會有我們再講的這個議題。
-----------------------------------------------------
基本上目前主要的有在做 server centric 的，大多都是 java 的framework ，
我在想是因為 java 的世界觀比較適合做這件事吧。
經典例子應該就是 Google Web Toolkit (GWT) 了，痞子好像很喜歡這東西。XD
http://code.google.com/intl/zh-TW/webtoolkit/overview.html
這類的 framework 應該有十來個吧，也包含像 JSF 這類的工具。
-----------------------------------------------------
不過上面所講得只是 server centric 的基本挑戰而已，
真正的挑戰是要如何提供夠豐富的介面讓使用者來用。
如果開發者以寫 html 的思維來寫 application ，
那這樣的幫助就比較有限，它還是需要寫很多的 code 來做一些簡單的事情。
而且現在 jQuery plug-in 或其他 js plug-in 這麼多，
總是會有開發者希望整合一些元件。
所以就冒出一個很重要的核心理念就是 designed by component ，
基本上我相信就算不是 server centric ，
designed by component 這個概念將會在未來的日子成為一個主流。
-----------------------------------------------------
什麼是 designed by component ？
html 中的元件太少了，根本不夠用，
連最基本的 calendar 都要拉js plug-in。
假設我今天有一個東西 就叫 <datebox id="hello" />
然後它會自動幫我產生一個textbox ，點擊後會有 calendar 冒出來，
我在後端只需要 hello.getValue() 就可以輕鬆取得使用者所輸入的資料，
這樣對開發者的負擔來講就降低了。
所以為了要做到這件事情，就必須去寫很多的 component (or widget) ，
他會包含 js/html/css/event 這四塊，
整合各種需要的介面，以此來達到想要的目的。
於是做了這些事情之後，我們就能達到寫 web application ，
就像在寫真正的視窗應用程式的效果，這感覺還不賴。
（想像一下寫 asp.net 的程式的寫法，
但是不用一直換頁的感覺，也不用去搞那麻煩的 updatepanel 。XD ）
題外話，我剛接觸這類 fw 時有一個疑惑是那 F2E是不是就不被需要了，
但即使是在 server centric 的角度，寫 js 這件事情也不是能完全捨棄的，
有些客製化的需求還是需要的，所以 GWT 有 JSNI 可以讓使用者自己寫，
只是它把寫 js 這件事情變得比較算是 optional 。
也可以把 F2E 的人力用在 widget 的開發上，就能夠一直累積共用元件，
我覺得這對 F2E 來講也好，對web世界來講也好，是雙贏的策略。
--
我一向都是看工作要做什麼就做什麼啊，我之前某份工作還跑去寫 rails 咧。XD
（題外話， ActiveRecord 是我目前看過最棒的 ORM 模型...）
畢竟 F2E 對很多地方而言，一直都是個很頭痛的任務，
雖然很多地方並不瞭解專職 F2E 有用的地方。
--
網頁上拉近距離的幫手 實現 GMail豐富應用的功臣
數也數不清的友善使用者體驗 這就是ｊａｖａｓｃｒｉｐｔ
歡迎同好到 AJAX 板一同討論。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.137.2.106
※ 編輯: TonyQ 來自: 114.137.2.106 (09/11 23:16)