ZK Web框架思想

我曾多次被要求提出一些有關ZK的意見。因此，根據我作為ZK用戶4年的經驗，以下是一些想法：

總體開發人員經驗，社區和文檔

“就是這樣”

ZK提供的大多數東西都能很好地工作，并且如果您以前開發過任何桌面Java應用程序，則使用該功能通常非常直觀。在2007年，我對RIA技術進行了比較，其中包括Echo2，ZK，GWT，OpenLaszlo和Flex。 Echo2和OpenLaszlo感覺不完整且有故障，并且似乎在任何地方都沒有適當的Maven工件。 GWT似乎更多是一項技術實驗，而不是一個很好的平臺。之所以放棄Flex，是因為缺少了一些重要的Maven工件，并且Flash對應用程序來說是不切實際的要求。另一方面，ZK感覺到了最“自然”的感覺，因此我很快就收獲了很多。在ZK的4年漫長旅程中，我獲得了很多“驚喜”時刻，當我越來越了解ZK并提高了我對框架的架構理解時。

如今，我對ZK中的哪些功能，哪些無效，什么有問題，什么沒有有一個很好的了解。但是，在獲得了所有這些好與壞的見解之后，我認為ZK是開箱即用的非常令人印象深刻的產品。當然，這樣做的缺點是該框架對新手來說隱藏了很多東西，以便易于使用，并且其中有些東西以后會咬住您 ，尤其是在您的應用程序具有大量用戶的情況下。

非常非常非常靈活

ZK非常靈活，具有很多集成。您是否要使用聲明性標記來構建組件樹？使用ZUL文件。您要堅持純Java嗎？使用richlets。您還可以集成JSP，JSF，Spring，并在zscript中使用多種語言。核心框架也非常靈活，如果遇到問題，您可以覆蓋很多東西。

不利的一面是，有很多正確的做事方法，甚至還有更多的搞砸方法。靈活性本身并不是負面因素，但是我認為ZK文檔并不能指導用戶充分了解ZK的最佳實踐。最佳實踐是什么？許多教程都使用zscript，但是由于性能原因，文檔也建議避免使用zscript。

論壇非常活躍

我認為ZK論壇是了解ZK的最佳場所之一。它非常活躍，并且線程從初學者到深層次的技術內容都各不相同。我幾乎每天都會閱讀論壇，有時還會幫助人們解決問題。有一件事情讓我有些煩惱：論壇中的英語通常不太好，人們經常問的問題太廣泛。我知道，批評非英語母語人士的作品是不公平的，尤其是當我自己不是母語人士的時候。無論如何，我認為存在這樣的障礙。例如，從ZK論壇和Spring Web論壇中抽取5個隨機線程。

在ZK論壇中看到的主題通常比Spring論壇中的主題更加詳細和集中，而不是“ 我是新手，我需要創建具有大量功能的應用程序x，請告訴我如何做所有事情 ”。人們顯然會花一些時間來提出良好而詳細的問題。您會看到，您必須在ZK論壇上花費更多時間才能理解這些線程。這不是任何人的錯，也不是壞事，這只是一個觀察。對我來說不幸的是，這意味著我在ZK社區中度過的有限時光只是用來理解人們在說什么。通常，僅當我立即知道答案或線程涉及一些深層次的技術知識時，才回答線程。

有很多文件

過去，ZK文檔分散，過時，并且一些更重要的內容完全丟失。近年來，文檔已經有了很大的改進，并且現在有針對ZK配置，客戶端ZK和樣式的單獨綜合參考。我認為今天的文檔非常好，通過閱讀文檔可以輕松回答大多數基本問題。

正如我上面提到的，ZK傾向于“公正地工作”。總體技術質量令人印象深刻，可與大多數Java Web框架相提并論，但我相信ZK的某些部分不太令人印象深刻。

卡在Java 1.4上

ZK是使用Java 1.4構建的，這極大地限制了其API的靈活性和內部代碼質量

對ZK內部代碼的負面影響

不能使用remove（）刪除ThreadLocals （調用set（null）可以防止泄漏所包含的對象，但不能正確刪除ThreadLocal）！
許多簡單的java.util.concurrent數據結構或對象將在其中運行的自定義同步代碼（ConcurrentHashMap，Semaphore，Atomic *等）
在StringBuilder適用的地方使用StringBuffer

沒有注解

我個人不喜歡大量使用注釋的框架，因為注釋是一種語言外的功能，通常您最終會得到基于注釋的，基于字符串的，沒有類型安全性的值。但是，我知道有些人會為基于他們的API而高興。

沒有枚舉

ZK API中有很多地方，適當的枚舉比當前使用的hacks要好得多。最嚴重的違規者是Messagebox。看看這個簽名：

public static int show(String message,String title,int buttons,java.lang.String icon,int focus)

嗯..神奇的整數讓我想起了SWT（這是一個很棒的API糟糕的庫）。讓我們想象一下帶有枚舉和泛型的替代版本：

public static Messagebox.Button show(String message,String title,Set<Messagebox.Button> buttons,Messagebox.Icon icon,Messagebox.Button focus)

更好，更類型安全。沒有更多的按位或魔術。如果使用Java 1.5，我可以在10分鐘內將其編碼到ZK中。

沒有泛型

這是卡在Java 1.4上最糟糕的部分。

我只列出一些我想看到泛型的地方：

API簽名中的集合值

org.zkoss.zk.ui.util.Initiator中的示例：

void doInit(Page page, Map args);

與

void doInit(Page page, Map<String, Object> args);

org.zkoss.zk.ui.Component中的示例：

List getChildren();

與

List<Component> getChildren();

類集合類

ListModel中的示例：

public interface ListModel {...Object getElementAt(int index);...
}

與

public interface ListModel<T> {...T getElementAt(int index);...
}

所有ListModel *類也應該是通用的（大多數擴展java.util.Collection）。
org.zkoss.zk.ui.event.EventListener

public interface EventListener {public void onEvent(Event event);
}

與

public interface EventListener<T extends Event> {public void onEvent(T event);
}

org.zkoss.zk.ui.util.GenericAutowireComposer

public class GenericAutowireComposer {protected Component self;...
}

與

public class GenericAutowireComposer<T extends Component> {protected T self;...
}

所有* Renderer類
org.zkoss.zul.RowRenderer中的示例：

public interface RowRenderer {void render(Row row, Object data);
}

與

public interface RowRenderer<T> {void render(Row row, T data);
}

令人印象深刻的服務器推送實現

默認的PollingServerPush具有延遲，如果有許多活動用戶，它將絕對殺死您的應用程序服務器。 CometServerPush更好，但是它不使用非阻塞IO，并且會阻塞servlet容器中的servlet線程。讓我們對此進行透視：

Tomcat 7.0的默認配置將連接器的最大線程數設置為200。這意味著，如果您有200個啟用了彗星的桌面，則Tomcat將停止響應其他請求，因為彗星正在使用所有線程。如果該實現使用的是Servlet 3.0或特定于容器的異步API，則即使只有一個線程，您也可以運行Tomcat。這當然會很慢，但不會停止工作！
同樣，CometServerPush需要ZK EE，因此普通用戶會陷入PollingServerPush的困境。考慮到服務器推送的營銷方式，這是一個很大的限制。但是，這并不奇怪：正確的非阻塞彗星很難實現，并且在從瀏覽器到servlet代碼的所有過程中都需要非阻塞組件。

腳本

我不喜歡zscript。許多年前它可能是一個不錯的功能，但我認為今天完全不應該使用它。為什么，為什么有人要用混合了ZUL模板的未經類型檢查的zscript替換類型安全的已編譯Java代碼？

“我可以使用Python / Ruby /…”。對于某些人來說，這可能是一個正確的觀點，但是您最終將在ZUL模板中處理無法維護的代碼
“保存文件時更改可見”。是的，但是我永遠不會為此功能付出太多。此外，使用JRebel可以獲得類似的效果。

因此，如果在zscript中放置“ Java代碼”（= BeanShell代碼），則可能需要重新考慮。

依靠反思

許多有用的功能都依賴于反射，這限制了編譯器可以為您檢查的內容。在許多Java庫/框架中，這是非常典型的事情，因此，它并不是ZK特定的事情。作為一個Scala用戶，我可以看到Java的局限性如何將大多數框架引導到反射/注釋的路徑。反射總是不能避免的，但是我認為如果大多數有用的功能都依賴反射，這是一個不好的信號。這是ZK中使用反射的一些功能：