ZKoss学习感受

ZKoss官网的Demo，基本过了一遍，组合着组件写了个简单图片浏览。界面如下。



功能很简单，可以上传图片，点击右边的图标，可以将图标显示出来，对显示出来的图标可以拖放到右边的图标栏里去（上传上来的图片不能拖放，对组件还不熟，有些功能不知道是没有还是找不到，以后再找。）调节游标可以对图片进行缩放。
代码很简单，不说了。说下对这个程序的体验。先看文档里面的一个图。


从图上可以看出ZK的工作流程。当有一个请求出现后，ZKLoader会根据请求装配出页面，并返回给用户，用户在页面上的操作，会触发不同的事件，ZK Client Engine将这些事件发送给ZK AU Engine 去处理，处理完成后再返回。下面是ZK文档里面的解释。

1. 当用户在浏览器中键入一个URL或点击一个超链接时,一个请求便被送到了
   Web服务器,如果URI符合ZK的配置[18],ZK 加载器则援引担任这一要求 。
2. ZK 加载器(ZK loader)加载指定的页面然后解释它,以据此创建和适的组件。
3. 当解释完整个页面后,ZK 加载器(ZK loader)将结果送到一个HTML页面。然
   后这个HTML页面被送回浏览器和ZK客户端引擎(ZK Client Engine)[19]一起。
4. ZK客户端引擎(ZK Client Engine)坐落在浏览器,以监视由客户的活动触发的
   事件,例如挪动鼠标,或改变某个值。一旦监测到,它就通知ZK AU引擎通过
   发送一个ZK请求[20]。
5. 当从客户端引擎接到 ZK 请求后,      如果有需要的话 AU 引擎就更新相应组件的内
           AU
   容。 然后, 引擎通过调用相关的事件处理程序(如果有的话)来通知应用程序。
6. 如果应用程序选择改变组件的内容,         添加或移动组件, 引擎通过 ZK 响应(ZK
                                    AU
   responses)将更新后组件的新内容送至客户端引擎。
7. 这些 ZK 响应实际上是一些命令,      这些命令指示客户端引擎如何更新 DOM 树的
   内容。

可以看出，ZK的处理都是基于事件的，且工作全部在后台完成，效率就可以想象了。ZK文档上也说了。

ZK 不适合在客户端运行多任务的应用程序,例如 3D 动作游戏,除非你写编写一个特殊的组件。
ZK 也不适合需要大量使用客户端计算能力的应用程序。

在写的例子中也感受到了这一点，在点击Upload上传中，明显感觉到了显示的延迟。在拖拉游标改变图片大小的时候，图片的改变也是有迟钝现象。
感觉到ZK可能只能用于小型系统。而我下面要做的是企业的一个网站发布平台，同一时间也就一两个人操作，还是没什么影响的。大点的项目还是考虑其他框架吧。或者等网速的提高吧