ZK – Ajax but no JavaScript

July 13, 2006 (Thursday) Leave a comment Go to comments

ZK – Simply Rich –  Ajax but no JavaScript

第一次看 ZK 已經忘了是什麼時候了,不過今天又回來看了一下,發現 ZK 真的是個好東西。如果要開發大型的 Ajax 專案非常值得考慮使用。ZK 的假想敵是 Echo2,ZK 認為 Echo2 使用的 Swing like 開發方式,是在假設開發人員都用過 Swing。而我個人也是非常反對這點,因為這樣美工人員完全無法進場。ZK 本身使用的是標準 XUL (XML User Interface Language) 的擴充稱為 ZUL,我目前沒有去了解 XUL 跟 ZUL 的差別有多少,但看起來差異不是很大。

ZK 也是一個 Java-based 的 framework,跟大部份的 Java web application framework 一樣,由一個 front controller servlet 去接所有 *.zul 的 request,server 會把 parse 成 html。而 ZUL 的語法大概如下:

<window title=”My First window” border=”normal” width=”200px”>
    Hello, World!
</window>

不難想像還會有 button, checkbox 等 ZUL 元件,這點跟 JSF 或是 OpenLaszlo 倒是差異不大。ZUL 的 tag 本身可以使用 css 或是 javascript。

在大型的 Ajax 專案裡,講究的是有沒有一個夠強的 framework 提供足夠的基礎元件、讓美工與開發人員簡便的合作。上面提到的幾個 framework:ZK、Echo2、JSF 和 OpenLaszlo,第一個出局的是 Echo2,不管它做得怎麼強大,網頁美工絕對不能拿來當 Swing 搞。第二個有問題的是 JSF,JSF 在 Struts 的影子之下,後端雖然強大,但前端仍然很少著墨。規範中前端的元件少得可憐,如果要找免費好用的元件恐怕不是很容易。再說 JSF 對 Ajax 支援有限,而且用起來綁手綁腳的,如果只是為了 Ajax 是沒必要跟自己過不去。OpenLaszlo 已經是很成熟的東西了,觀念上跟 ZK 非常接近,同一份 code 能產生 Flash 跟 DHTML 兩種模式實在是讓人讚嘆。只是用的是獨規的語法,比起 ZK 用類 XUL 的語法好像差了一些。在切割 MVC 這三件事上面 OpenLaszlo 也有點模糊不清,而且以我對 OpenLaszlo 粗淺的了解,沒有看到 control tag,反之 ZK 對於 if condition, iterating 等等都有考量到,這也是 ZK 優勢所在。ZK 還有一個好處是看來 extends 它的 class 或是做 custom 的元件不是很難。但是 OpenLaszlo UI event 直接 call Web Service 的模式可謂是 SOA 的奧義,非常有用。

總合以上,我覺得 ZK 跟 OpenLaszlo 都是很值得考慮使用的。可能你會發現怎麼沒提到 Dojo?因為 Dojo 現在已經成為 JavaScript component 的地下標準了,每家都讚助它,使用它。ZK 已經結合 Dojo,OpenLaszlo 也有在做這件事。看完 ZK 跟 OpenLaszlo,JSF 又再被我打入冷宮了,我寧可用 Spring Web Flow 去把 ZK 或 OpenLaszlo 的頁面接起來也不想用那一大包沒多少建設的東西。要不就使用奧義:OpenLaszlo + BPEL + ESB 往軟體工程的烏托邦前進。可惜的是 Gavin King 的 JBoss Seam 綁死用 JSF,就連帶被判出局了。之前有人做一個 HSE (Hibernate + Spring + Echo2) 的 framework,是時候來做 OLSH (OpenLaszlo + Spring + Hibernate) 或是 ZSH (ZK + Spring + Hibernate) 了。

technorati tags:, , , , , ,

Blogged with Flock

Advertisements
  1. 不錯
    July 14, 2006 (Friday) at 12:53

    分析的不錯。謝啦!不知道 ZK 文件清不清楚。

  2. July 14, 2006 (Friday) at 15:29

    就我看過的部份來判斷,ZK 的文件算是相當不錯了。ZK 跟 OpenLaszlo 的線上 example 都可以直接現場改然後看結果,這個可能比萬言書更有用。

  3. sh
    October 20, 2006 (Friday) at 13:36

    请帮忙看看 http://www.sokiki.com 使用zk技术合适么

  4. October 20, 2006 (Friday) at 22:41

    http://www.sokiki.com 這個站在我看來與一般的搜尋網站沒有太大的不同。
    使用 ZK 可以把相對較亂的 jsp 網頁重整成為比較整齊的 ZUL 格式。
    不過那個網站沒有看到太多 Ajax 的動作,使用 ZK 沒有太多發揮的空間。
    我覺得在沒有大量 Ajax 需求下,要不要採用 ZK 取決於團隊的人員以及系統未來發展的方向。用 ZK 絕對不會不適合,只怕殺雞用牛刀而已。

  5. January 31, 2007 (Wednesday) at 22:37

    吐槽一下,如果從美工人員無法進場的角度來看,ZK 也有同樣的毛病,考量一段ZK 程式碼:

    The first panel.
    The second panel.

    像這樣的 XUL tag,我想只有超級美工才能編輯吧!

  6. January 31, 2007 (Wednesday) at 22:40

    Sorry, tag 被濾掉了,大概是這樣:

    〈tabbox〉〈!– if not specified, the default mold is assumed. –〉
    〈tabs〉
    〈tab label=”Default”/〉
    〈/tabs〉

    〈/tabbox〉

  7. January 22, 2010 (Friday) at 22:25

    請問,ZK的架構看起來是以來Server端進行XUL的轉碼進而產生一般HTML code。

    那麼,就伺服器JVM的資源使用程度來說,ZK的要求高嗎?

    • February 5, 2010 (Friday) at 10:38

      @gVee 如你所說的 ZK 需要在 server side 保留每一個 client 的 component tree. 如果元件很覆雜的話, 就佔有一定的空間.

      就這點來看~ 在資源方面就是每一個 concurrent user 所佔用的 memory 會較大. 這會延伸出來的問題就是
      1) 同等級 server 可接愛的 concurrent user 會低於沒有 keep component tree 的方式~
      2) 如果很注重 High Avaliability 時 session replication 的 cost 會更高.

      總之, 如果只是一個企業內使用的 web ap, concurrent user 畢竟有限, 就不用太擔心了.
      如果是 public site / app ~ 我建議必需要做詳細的 capacity 計算跟測試.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: