ZK框架深度解析:优缺点与技术亮点

ZK框架深度解析:优缺点与技术亮点

我曾多次被要求提出一些有关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 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 args);

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

List getChildren();

List getChildren();

类集合类

ListModel中的示例:

public interface ListModel {

...

Object getElementAt(int index);

...

}

public interface ListModel {

...

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 {

public void onEvent(T event);

}

org.zkoss.zk.ui.util.GenericAutowireComposer

public class GenericAutowireComposer {

protected Component self;

...

}

public class GenericAutowireComposer {

protected T self;

...

}

所有* Renderer类 org.zkoss.zul.RowRenderer中的示例:

public interface RowRenderer {

void render(Row row, Object data);

}

public interface RowRenderer {

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开发–快速教程

推荐文章

烤箱版【烤板栗】
36365最新线路检测

烤箱版【烤板栗】

📅 07-09 👁️‍🗨️ 2883
耳机森海塞尔CX 300-II的评论
365bet亚洲

耳机森海塞尔CX 300-II的评论

📅 07-28 👁️‍🗨️ 4493