ZK Web框架思想

最新推荐文章于 2024-10-15 13:37:46 发布

dnc8371

最新推荐文章于 2024-10-15 13:37:46 发布

阅读量495

点赞数

文章标签： spring java 编程语言 python 人工智能

ZK框架凭借其直观易用、高度灵活性和丰富的集成特性脱颖而出。然而，它对新手隐藏了许多复杂性，且由于基于Java 1.4，缺乏现代语言特性如泛型和枚举。此外，服务器推送实现和脚本语言zscript也存在效率和可维护性问题。尽管有活跃的论坛和不断改进的文档，但ZK的某些设计选择可能会在大型项目中带来挑战。

摘要由CSDN通过智能技术生成

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