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

總體開發(fā)人員經(jīng)驗，社區(qū)和文檔

“就是這樣”

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

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

非常非常非常靈活

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

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

論壇非常活躍

我認(rèn)為ZK論壇是了解ZK的最佳場所之一。 它非?；钴S，并且線程從初學(xué)者到深層次的技術(shù)內(nèi)容都各不相同。 我?guī)缀趺刻於紩喿x論壇，有時還會幫助人們解決問題。 有一件事情讓我有些煩惱：論壇中的英語通常不太好，人們經(jīng)常問的問題太廣泛。 我知道，批評非英語母語人士的作品是不公平的，尤其是當(dāng)我自己不是母語人士的時候。 無論如何，我認(rèn)為存在這樣的障礙。 例如，從ZK論壇和Spring Web論壇中抽取5個隨機線程。

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

有很多文件

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

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

卡在Java 1.4上

ZK是使用Java 1.4構(gòu)建的，這極大地限制了其API的靈活性和內(nèi)部代碼質(zhì)量

對ZK內(nèi)部代碼的負(fù)面影響

• 不能使用remove（）刪除ThreadLocals （調(diào)用set（null）可以防止泄漏所包含的對象，但不能正確刪除ThreadLocal）！
• 許多簡單的java.util.concurrent數(shù)據(jù)結(jié)構(gòu)或?qū)ο髮⒃谄渲羞\行的自定義同步代碼（ConcurrentHashMap，Semaphore，Atomic *等）
• 在StringBuilder適用的地方使用StringBuffer

沒有注解

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

沒有枚舉

ZK API中有很多地方，適當(dāng)?shù)拿杜e比當(dāng)前使用的hacks要好得多。 最嚴(yán)重的違規(guī)者是Messagebox。 看看這個簽名：

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

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

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

更好，更類型安全。 沒有更多的按位或魔術(shù)。 如果使用Java 1.5，我可以在10分鐘內(nèi)將其編碼到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 *類也應(yīng)該是通用的（大多數(shù)擴展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); }

令人印象深刻的服務(wù)器推送實現(xiàn)

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

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

腳本

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

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

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

依靠反思

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

• 任何不使用component.addEventListener的事件偵聽。 這包括擴展GenericEventListener的所有類（例如，除MultiComposer之外，所有ZK提供的Composer類）
• 數(shù)據(jù)綁定
• ZUL模板中的EL表達(dá)式

參考： 關(guān)于ZK Web框架的 想法 ：總體經(jīng)驗和關(guān)于ZK Web框架的想法： Jawsy Solutions技術(shù)博客上 JCG合作伙伴 Joonas Javanainen的技術(shù)資料

相關(guān)文章 ：

• SmartGWT入門，提供出色的GWT界面
• 高級SmartGWT教程，第1部分
• 使用Spring Security保護(hù)GWT應(yīng)用程序
• GWT EJB3 Maven JBoss 5.1集成教程
• Spring MVC3 Hibernate CRUD示例應(yīng)用程序
• Spring MVC開發(fā)–快速教程

翻譯自: https://www.javacodegeeks.com/2012/01/zk-web-framework-thoughts.html

總結(jié)

以上是生活随笔為你收集整理的ZK Web框架思想的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。