解惑

解己之惑,解人之惑

标签:Web

服务器端的分页功能

ZK的分页功能默认是在客户端做的,也就是服务器端返回所有的结果,然后客户端每次显示一页的数据,翻页的时候不提交请求到服务器端重新查询。如果服务器端返回的结果比较多,这种方案就不太好了,要实现服务器端的分页也很简单,在使用Listbox或者grid的时候不要使用mold="paging",而是添加一个Paging组件:
<paging id="groupListboxPaging" pageSize="10"/>
然后给Paging增加事件监听:
        final Paging paging = getPaging(pagingName);
        paging.addEventListener(
            "onPaging", new EventListener()
        {
            public void onEvent(Event event)
            {
                PagingEvent pagingEvent = (PagingEvent) event;
                int pageNumber = pagingEvent.getActivePage();
                int firstRow = pageNumber * paging.getPageSize();
                queryInfos.get(listName).getPageInfo().setFirstRow(firstRow);
                refreshList(listName);
            }
        });
代码中的getPaging和refreshList都是我自定义的方法,getPaging很简单,因为我的这个代码是在自定义的Window类里面的,所以:
    protected Paging getPaging(String pagingName)
    {
        return (Paging) getFellow(pagingName);
    }
而refreshList就比较复杂一些了,根据传入的list的名字查询结果并刷新list:
    public void refreshList(String name)
    {
        try
        {
            getListbox(getListboxName(name)).setModel(new BindingListModelList(list(name), false));
        }
        catch (Throwable t)
        {
            handleException(t);
        }
    }
核心就是拿到Listbox或者Grid然后setModel。

越来越喜欢ZK了

这几天一直在研究ZK,感觉是我做web开发以来见到的最好的Web的UI框架。
美国那边的Consultant在给我们做UI,但是他们的UI的框架还在开发中,而且好像还在根据我们的一些要求不断的修改他们自己的框架,所以进度很慢,上个星期给了一个final drop,但是问题多多,发了一个问题列表,到现在也没有任何回应,我就趁着这个功夫用ZK做了一份功能和UI类似的,从代码量上讲比那个少,而且最重要的是UI的代码很干净整洁。

以后会大力推广这个东东,把我的经验都整理出来。

ZK确实不错

前几天抱怨没有好的Web框架,Bob推荐了ZK,这几天有时间的时候试了下,感觉确实不错。
用ZK做原型确实不错,数据都可以是hardcode的,ZK的文档基本上都是在这种模式下的,但是我打算做的是那种真正可以运行的demo,可以连接我们的后台Service跑的,这样搞的时候发现Sample奇缺,也没有好的最佳实践,主要是ZK本身确实很灵活,既可以在view里面嵌script实现,也可以写类来实现,而且也可以写类来创建组件,慢慢的摸索了下,根据自己的偏好搞出基本的东西来了。以后有时间搞完善了就放出来给大家参考吧。
ZK的几个主要问题:

  • 没有真正的应用级的Sample,网站上的几个Real World Application都太简单
  • 现在应用的范围似乎不广,资源也就不那么多
  • License比较难过,要么是GPL,要么是Commercial,所以现阶段只能拿来练手和做原型。

我比较认可的特性:

  • 浏览器兼容性不错,几乎支持所有常见的浏览器
  • 入门比较容易,入门级的文档还是比较完善的,参考手册也还可以接受
  • 专注于Web,没有太去在意MVC之类,当然也并不限制你用MVC
  • 缺省情况下的设置都比较好,例如ListBox或者Grid里面的各列的宽度以及默认宽度100%之类的
  • 界面比较漂亮
  • 功能比较齐全

Web开发为什么没有UI的王者

做了这么多年的Web开发,感触最深的就是UI始终没有王者,虽然Web的Framework是一堆一堆,但是大家的注意力似乎都在MVC、Template以及Layout,以Java来说,历经了Servlet、JSP、TagLib以及JSF的变迁,当然其他的第三方的东西就更多的,但是就是没有一个成为事实标准,Struts勉强算一个强者,因为普及度最高,但是依然不能解决UI的表现力和交互性问题。我想这也是为什么现在AJAX以及RIA喧嚣尘上,但是无论是以JS为基础的AJAX还是RIA(以Flex和JavaXF为代表)的方案都不能解决全部的问题,无论是AJAX还是RIA,在交互性上都有不错的表现,特别是RIA,能够做出很酷很炫的界面,而以JS为基础的UI库也是不胜枚举,就是没有出现强者,各自分据一小块开发者。
这个问题应该是已经被问了无数次,但是迄今没有出来很好的方案,在最近的两年内都不太可能出现什么转机,唉。。。

更新:
下午看infoq刚好看到一个针对这个问题的访谈,访谈对象都是一些典型阵营的人,很有意思,看完的感受就是:各自力挺自家的方案。不管是否出于商业利益,这个访谈的结果只能更加证明web的UI端的混乱不会结束。也许不同的方案确实要应用到不同的场景,以内容为主的网站更加倾向于原来的HTML为主的方案,对交互性要求稍高的可能用AJAX,对交互性和表现力要求最高的就用RIA。

表现层是最难解决的问题

在Web开发中,表现层是最难于通用化的,个人的感觉,Tapestry是一个不错的思路,可惜学习起来并不简单,而且也需要积累才能真正的简化开发。其它的表现层框架我都不是很看好,目前我的思路倾向于使用类生成页面,和模型层绑定,这样在产品或者大型项目中可以大大的简化工作量,也减少很多问题。目前,公司的产品中虽然是使用的这种思路,但是力度不够,组件太少,和模型的绑定也不够,需要写的代码太多,一种问题在不同的地方都需要小心,搞得QA也是很不爽。
而且表现层似乎也是搞开发的人中最不喜欢做的部分,因为“技术含量太少”,基本上堆代码肯定可以搞定。虽然我也不喜欢做表现层的工作,但是必须承认,如果能够实现一个易于使用的表现层框架,对于整个项目的贡献是很大的,至少有30%的代码量,因此可以简化的工作量实际上很多。公司考虑将更多的工作转移到中国来做,希望自己有机会能够改变这个情况,让表现层的工作更加的简单。

打算造一个大轮子

有感于这次单元测试框架的设计实现过程,决定慢慢的造一个大轮子:一个自己的web框架,初步计划是自己用,不考虑太通用,目的就是简单快捷的创建web应用,可以很方便的增加功能,基本上就是像ror一样简单快捷。
当然这个框架不会全部重写,肯定会基于现在的一些开源的组件搭建。但是肯定会排除spring和hibernate,因为这两个对于我而言是很大的轮子了。我需要的功能相对简单,我更喜欢基于规则而不是基于配置,很多东西其实没有必要配置,定义一套规则遵循就可以了。
初步拟定可能要使用到的一些组件是:

  • OGNL
  • prototype.js
  • overlib.js

Cherami的由来和消失的VRML

很多人奇怪我的网名或者英文名为什么叫cherami,其实这个词是一个法语词,意思是亲爱的朋友,一般指男性,还有一个词是cherame,意思一样,指女性。好像是在看一本小说的时候无意中看到的。后来上网的时候就想,什么名字别人不太可能想到用到?我觉得cherami是个好的选择,后来的事实证明我的猜测是正确的。
其中我遇到的最大一次挫折就是在中国人注册,这个名字已经被人使用了,费了很大的劲查到那个人的QQ,就在QQ上要那个人把那个ID让给我,后来慢慢知道她是一个MM,是学法语的,她说我是男的,应该用cherame,她说cherami才是指的女性。她经不住我的纠缠,答应让给我,后来却又不干了。

后来有一件很巧的事情,就是在图书馆里面看到介绍VRML的书,感觉这个是未来Web的方向,那本书最开始的介绍也是说“VRML的英文全称为Virtual Reality Modeling Language,即虚拟现实建模语言,它是第二代WWW的标准语言。”,学习了几个月,掌握了基本语法。后来想到注册一个自己的域名,试了下cherami.com,没想到竟然是一个使用VRML建立的虚拟世界交友网站,可惜那个时候还非常的简单和粗糙。

现在VRML好像已经销声匿迹了,希望cherami不会。但是我更希望真正的下一代3D的Web语言能够尽早出现,这样我们就可以享受一个真正的虚拟世界,而不是在网络游戏中沉沦了。

© 2024 解惑

本主题由Anders Noren提供向上 ↑