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

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

“就是這樣”

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

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

非常非常非常靈活

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

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

論壇非常活躍

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

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

有很多文件

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

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

卡在Java 1.4上

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

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

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

沒有注解

我個(gè)人不喜歡大量使用注釋的框架，因?yàn)樽⑨屖且环N語言外的功能，通常您最終會(huì)得到基于注釋的，基于字符串的，沒有類型安全性的值。 但是，我知道有些人會(huì)為基于他們的API而高興。

沒有枚舉

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

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

嗯..神奇的整數(shù)讓我想起了SWT（這是一個(gè)很棒的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ù)擴(kuò)展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ù)器推送實(shí)現(xiàn)

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

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

腳本

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

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

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

依靠反思

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

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

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

相關(guān)文章 ：

• SmartGWT入門，提供出色的GWT界面
• 高級(jí)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框架思想的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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