我曾多次被要求提出一些有关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中使用反射的一些功能：

• 任何不使用component.addEventListener的事件侦听。 这包括扩展GenericEventListener的所有类（例如，除MultiComposer之外，所有ZK提供的Composer类）
• 数据绑定
• ZUL模板中的EL表达式

参考： 关于ZK Web框架的 想法 ：总体经验和关于ZK Web框架的想法： Jawsy Solutions技术博客上 JCG合作伙伴 Joonas Javanainen的技术资料

相关文章 ：

• SmartGWT入门，提供出色的GWT界面
• 高级SmartGWT教程，第1部分
• 使用Spring Security保护GWT应用程序
• GWT EJB3 Maven JBoss 5.1集成教程
• Spring MVC3 Hibernate CRUD示例应用程序
• Spring MVC开发–快速教程