语源科技BlogJava-闲人野居

回顾一下最近的生活

布衣郎 — Sun, 25 Oct 2009 10:49:00 GMT

    现在，人变得越来懒了，不知道是不是人老了的缘故，还是一直闲着的缘故。博客也n久没有更过新了，不是不想写，实在是懒得写，一想写点东西，就变得无语了，最后还是不了了之了。
    上个月开始，正式有了一份稳定收入的工作，不容易啊，好像已经是很久很久以前的事情了，当然这虽然只是一份兼职工作，但是感觉还是比较有意思，毕竟自己还是一个能做出贡献的人啊。还是很感谢我那哥们的，生病那么久了，虽然一直做着零散的事情，不过毕竟还是没有稳定的收入来源，现在可以基本解决了后顾之忧了。
    这段时间，自己做的一个开源项目，终于弄的差不多了，不过一直懒的缘故，总是写一点，停一点，这回终于还是差不多写完了，正在恶补文档，想想开源真不是一件简单的事情，要让人家快速的接受你的东西，还能让人家快速的学会，并使用，没有充分的文档是不行的。
    zframework，我临时取的名字，一个简单的osgi开源框架，无聊的时候，慢慢的弄起来的，不知不觉已经搞了好久了。本来一直想放上去的，一直怕写的太难看，被人糗，总不好，所以一直在不停的重构中。估计下个月，应该可以收工了。
    前段时间帮人搞了一个网店的程序，看着看着，也想搞搞这方面的东西，等完善的差不多了，也开源算了，看看java的网店，还是没有php的多，争取做点贡献吧。
    其实，感觉现在生活还算不错，至少老天还是比较眷顾我的，好几年都这么过去了，也算不错了。接下来的日子，先帮哥们把网站弄起来，毕竟那是我的衣食父母，感觉有点事情也是不错的。都奔4的人了，是应该做点事情，不用再管什么得失了，只要感觉不白活就行了。
    先啰嗦到这，还有点文档要写，写一会就看电影去，生活乐无边。

布衣郎 2009-10-25 18:49 发表评论

osgi 入门三关于类装载机制

布衣郎 — Tue, 17 Feb 2009 08:49:00 GMT

osgi一个最大的特色就是使用不同的ClassLoader,让多个bundle共享一个虚拟机，而每一个bundle使用单独的ClassLoader。
如下图所示：

对于资源和类的装载主要包括以下三种途径：
Boot classpath：启动类环境，包括java.*包和相应的实现包。
Framework classpath:osgi框架拥有一个独立的ClassLoader，用于装载框架接口类，以及相应的实现类。
Bundle Space:每个bundle包括了与bundle相关的jar文件，以及相关的资源。

对于一个类的查询，主要通过以下途径进行查询：
1.从Parent ClassLoader中装载
2.从Import Package中查询类路径。
3.从Required bundles中查询类
4.自身bundle，相关ClassPath
5.相关的插件片段Fragment。
如下图

这么说起来，还是比较的抽象，还是从一个实例来具体的分析。
假设有如下Bundle,
相关的描述文件如下：

Bundle:org.zframework.core
Manifest-Version: 1.0
Bundle-Name: core
Bundle-SymbolicName: org.zframework.core;singleton:=true
Bundle-ClassPath: .
Import-Package: net.sf.ehcache;version="1.3.0",
net.sf.ehcache.config;version="1.3.0",
net.sf.ehcache.event;version="1.3.0",
org.osgi.framework;version="1.4.0",
org.osgi.service.log;version="1.3.0",

Require-Bundle: org.eclipse.equinox.common;visibility:=reexport,

Export-Package: org.zframework.core;version="1.0.0",

现在创建了如下的类：

package org.zframework.core;
import java.net.URL;
import java.util.Collection;
import net.sf.ehcache.Cache;
import net.sf.ehcache.CacheManager;
import net.sf.ehcache.Element;
import org.osgi.framework.BundleContext;
public class EhCacheManager extends AbstractCacheManager implements
    BundleContextAware {
    private String cacheFile;
    private BundleContext context;
    private CacheManager manager;
    public Cache getCache(String cacheName) {
    Cache cache = manager.getCache(cacheName);
    if (cache == null) {

    }
    return cache;
    }

}

假设有一个Bundle org.zframework.model需要使用此类，描述如下：

Manifest-Version: 1.0
Bundle-Name: model
Bundle-SymbolicName: org.zframework.model;singleton:=true
Bundle-ClassPath: .
Import-Package: javax.persistence;version="1.0.0",
  javax.persistence.spi;version="1.0.0",
  org.osgi.framework;version="1.4.0",

Require-Bundle: org.zframework.core

类Model

package org.zframework.model;
import java.net.URL;
import java.util.Collection;
import org.zframework.core.EhCacheManager ;
public class Model{
    private EhCacheManager manager;
    public Object getCache(String key) {
    Object o = manager.getCache(key);
    return o;
    }

}

下面简单说明一下装载过程：
在装载Model类时，
1.对于java.*类的装载，由相应的Boot ClassLoader 装载
2.装载EhCacheManager，
    1.在Import-Package中查询是否存在匹配中的org.zframework.core包声明，如果有，则委派给org.zframework.core包声明的Bundle进行装载，本例没有，则继续。
    2.在Require-Bundle中查询所有的Export声明包，判断是否存在org.zframework.core匹配。本例中，应该存在。如果不存在，则执行步骤2.3
    3.查询本bundle的类路径，是否有此类存在。不存在，继续2.4步骤
    4.查询所有的fragments bundle（特殊的bundle）类路径。不存在，继续2.5步骤
    5.判断是否使用DynamicImport-Package: * 声明，如果是则查询所有的bundle中声明的Export包。如果还是不存在，则抛出ClassNotFound例外。
关于DynamicImport-Package: * ，这是比较极端的设置，一般不会推荐使用，主要破坏了相关的封装性。
完整的类查询如下图：

关于类装载机制基本就是这些，对于初学者来说，这还是会有些困惑的。

布衣郎 2009-02-17 16:49 发表评论

osgi 入门二之关于osgi

布衣郎 — Sat, 14 Feb 2009 08:28:00 GMT

摘要: 前面通过一个例子简单的介绍了如何快速的开发一个osgi应用。下面来具体说明一下什么是osgi，以及osgi 能做什么，为什么使用osgi,以及到底osgi能带来什么益处。阅读全文

布衣郎 2009-02-14 16:28 发表评论

osgi 入门

布衣郎 — Thu, 12 Feb 2009 12:36:00 GMT

摘要: 接触了osgi也这么久了，其中也走了不少的弯路。为了更好的推广osgi，并避免新手能少走一些弯路，接下来的几篇文章，我会通过几个简单的实例，来介绍一下如何快速的掌握osgi。其实，网上有不少好的文章推荐，顺便也可以比较一下。BlueDavy的osgi 实战是值得推荐的，当初也是看了之后，少走了很多弯路。参见网址：http://www.blogjava.net/BlueDavy/。 ModuleFusion 也是一个不错的项目，里面集成了现有的优秀框架，包括hibernate,guice,wicket等。参见网址：http://code.google.com/p/modulefusion/。阅读全文

布衣郎 2009-02-12 20:36 发表评论

温故而知新，回顾一下osgi bundle

布衣郎 — Sun, 08 Feb 2009 12:33:00 GMT

    本年的基本工作目标，基本确立了，重点还是osgi，先来回顾一下以前所做的。osgi看了看规范，目前还是4.1，这相差不大。equinox的版本，目前正式的算是3.4.1，以前用的为3.3，相差也不大。还是继续使用3.3吧，毕竟也懒得更新eclipse了，老是用新版本也不是个办法。看了一下jetty bundle,目前已经出来6.1.7了，相差还是有点，不过估计3.3也能支持6.1.7。servlet规范使用了2.5，其实2.4已经足够了，我又不需要jsp，不必使用新的el引擎。dm还是使用spring-dm，目前为1.2m，这个算是比较有大的发展，我现在用的还是1.0.2的，dm这一块估计变动也不会太大，其实，如果不是需要spring的一些其他功能，还不如直接用equinox的dm算了，为了赶个时髦，还是用spring算了，毕竟用惯了ServiceReference。
   整理了一下，基本上的bundle还是那么几个：
   osgi 核心：
    org.eclipse.osgi_3.3.2
    org.eclipse.osgi.services_3.1.2
   equinox:
    org.eclipse.equinox.common_3.3.0
    org.eclipse.equinox.registry_3.3.1
    org.eclipse.equinox.http.jetty_1.0.1        (需要更新）
    org.eclipse.equinox.http.registry_1.0.1
    org.eclipse.equinox.http.servlet_1.0.1
    org.eclipse.equinox.preferences_3.2.1
    org.eclipse.equinox.log_1.0.1
    org.eclipse.equinox.preferences_3.2.1
必须的bundle:
    org.mortbay.jetty_5.1.11                （需要更新）
    javax.servlet_2.4.0                    （可选更新）
    org.apache.log4j_1.2.9
    org.apache.commons.logging_1.0.4
spring bundle:
    org.springframework.spring_2.5.2            （可选更新）
    org.springframework.bundle.osgi.extender_1.0.2    （可选更新）
    org.springframework.bundle.osgi.core_1.0.2    （可选更新）
看了看一个基本的应用就需要这么多bundle，也够呛的，这还不算上hibernate,webwork,等其他第三方jar.

布衣郎 2009-02-08 20:33 发表评论

该是考虑做点事情了

布衣郎 — Sat, 07 Feb 2009 12:28:00 GMT

荒废了很长时间了，看了看上次写的blog，还是去年1月份的，想想也停了太长时间了。想想这一年间，不知道在做些什么，技术资料也看了不少，不过真正能够掌握的又实在太少，总是停留在表面，而不去深入。2009了，也快30而立了，对于一个老程序员来说，也到了和黄金年龄说再见的时候了。转行想想，也不太可能，向管理发展，还是不太靠谱，所以还是继续做自己的老本行，踏踏实实写程序吧。
想了想2009该做的几件事情，
    1，还是继续osgi之路，毕竟前面已经做了很多了，soa太遥远，毕竟还是osgi实在。原先做的osgi web框架太乱，还是采用webwork2作为基本的web框架，或者使用xwork2作为核心，使用部分struts引擎。
      2.研究一下规则引擎，看看jboss的rule
      3.复习一下工作流引擎，好几年没有玩了，从以前的jbpm 到osworkflow，试试能不能和osgi整合
    4.建一个稳定的ajax框架，ext效率实在低下，还是找别的吧
      5.熟悉熟悉soa，虽然soa概念大于技术，不过还是需要看看的
基本的工作也就这些了，如果能搞定这些，这一年基本上还是会有收获了。

布衣郎 2009-02-07 20:28 发表评论

关于服务端生成js的构思

布衣郎 — Wed, 02 Jan 2008 10:36:00 GMT

    研究了ext很久了，一直想为ext直接封装一个服务端组件。考虑到ext组件的构建都是需要使用js来完成，那么服务端生成的代码也就是js而不是html。
    如果采取纯Ajax的方式，类似于Echo2的构造，不过这样对于Session可能是一个负担，同时可能会造成服务端的拥堵。不过使用纯Ajax有个好处，就是js只需要装载一次就行了。而如果使用各个不同的页面方式，则需要多次装载ext的js文件，这对于网络也是一个压力。
    不过创建的初衷，此框架主要还是使用于内部网，这样对于性能方面的担心可以略过了。
    设计流程如下：
    类似于Jsf的请求流程,提供Lifecycle，基本上也就五个生命周期，apply request,process validators,update model,invokeAction,render ajax。
    先不考虑其他的生命周期，先来处理render ajax部分。基本构思还是以render xml为主，主要的格式如下：

<message xmlns="http://www.esoft.org/servermessage">
<lib>
<js url="widgets/ext-component"/>
lib>
<script>Ext.QuickTips.init();script>
<content cid="W9"><div id="W39"/>content>
<remove>Ext.get('W29').remove();remove>
message>

lib 中主要用来装载ext的各个组件js,这样不需要一次装载。
script，主要的执行js脚本
content用于创建相应的html
remove相应的删除js脚本

为什么需要增加remove而不是把所有的脚本都放在script中。
这是由于整个处理都在一个页面中，为了能按照顺序执行相应的脚本，remove的脚本需要优先执行，当两个组件不停的切换的时候。

client 对于脚本的解析流程如下：
首先分批装载js url
当所有的js装载完成后
执行remove 脚本
遍历content,增加相应的html node
执行script脚本。

对于页面的生成，基本上没有什么问题。
只是如果采用这种方式，可能目前来说只能依赖于ext这个框架，对于服务端的灵活性也就大打折扣，不过既然是为了ext而做的，那也就无所谓了。

不知道各位对这种生成方式有什么不同意见，期待讨论。

布衣郎 2008-01-02 18:36 发表评论

ext 之我见

布衣郎 — Fri, 28 Dec 2007 11:01:00 GMT

    最近的这段时间，感觉Ext挺火的。接触Ext还是半年前的事情了，那时候就想对Ext进行封装，做一个服务端的Ajax框架出来。可由于身体的原因，还是搁浅了。
    使用Ext是从1.1开始的，那时候觉得Ext，几乎已经简化了所有的客户端脚本。就算不会js，不会Ajax，使用Ext也可以很容易的搭建不错的页面。而且Ext在兼容性上面做的也算不错，至少我在ie 6,ie 7 ff和opera 9上运行demo的时候基本上没有什么问题。当然最主要的一个吸引我的因素是，和其他的框架相比，Ext的界面做的比较的出色，就美观而言，算是perfect了。
    随着Ext 2.0的正式发布，关注Ext的人也越来越多。Ext变得越来越大众化，这是一件值得高兴的事情，毕竟使用Ext能够帮助简化不少的js代码，而且对于html代码的编写，是数量级的减少。
    让数据和内容分离，一直是Ajax所提倡的，而Ext可以完全做到这些。Grid作为表示组件而Store作为数据存储，数据可以通过Reader来读取，包括xml和json，或者其它的自定义实现。
    组件化，这是Ext最大的特色。所有的组件都继承Ext.Component这个基础类。而Ext.Component继承Ext.util.Observable，让组件事件的处理变得更为的强大和灵活。Ext可以模拟所有的桌面事件，如双击，拖拽，这些只有在桌面程序中才见到的，而这些事件的处理变得和桌面程序一样的简捷。
    动画以及控件的resize和drag，这些比较难处理的js，在Ext中变得实在很简洁。基本的Window都有drag和resize行为，动画更是简单。当然这些功能只是次要的。不过在ria中，这些功能又都是不能缺少的。
    当然Ext的诟病也不少，如性能，这个在浏览器中关键的因素。完整的Ext.js需要400多k，随着宽带的普及，以及Ajax技术的应用，这个应该不成为问题。真正的问题在于Ext都是使用js构建页面，其中的html代码，可能比较的繁琐，过多的div的使用，可能也会是一个灾难。如Ext.Button这个组件的表现层一样。当然Ext也提供了自定义的html模板功能，这个问题也就可能不是问题了。最后毕竟Ext只是一个客户端的组件实现，和服务端的集成，还需要自己实现。不过Ext在这个方面，也提供了很多的简化功能，如延迟装载，数据读取等。
    当然，个人还是比较的看好Ext，希望这个框架能够越走越好。

布衣郎 2007-12-28 19:01 发表评论

回来了

布衣郎 — Thu, 27 Dec 2007 11:00:00 GMT

很久没有更新了，由于过去的半年都在医院呆着，也就没有时间去维护自己的blog了。不过发现浏览的人还是挺多的，有点对不起大家，毕竟没有办法回复。
半年过去了，看了看网上的技术，还好新的东东不太多，不然又得需要花费大量的时间去学了。不过，现在对于新的技术，也没有以前那种热情了，其实搞软件的还是得要踏踏实实的打好基础，毕竟内涵的东西都差不多，不像硬件，更新的速度实在跟不上。
编程也好多年了，看着周围的人，基本上都已经从编程开始转向管理，在国内就是这样。不过我还是不想放弃，继续做一个程序员，继续开发。喜欢编程没有理由，看着一行行的代码，内心总是有种莫名的喜悦，毕竟这是自己创造的。就像小时候搭积木一样，完成后总是感觉很有成就感。
当然，这种感觉，有时候可能会被压抑。在公司的时候，老是重复着基本的东西，失去了创造的乐趣。而今离开了公司，终于不再感觉压抑，做一个自由的程序员是快乐的，不过也可能是悲哀的。为什么人家老外能写出那么好的程序，而看看国内，好的程序真的不多，同样都是搞程序的，差别怎么能这么大，可能这就是环境的缘故吧。
在住院的时候，只要有时间还是会写几行代码，虽然身体不允许，不过还是没有办法停止。也许这就是程序员的天性，离开了程序，我发现我做别的都没有什么兴趣。而今，已经离开了医院，又可以开始自己的程序员生涯，不过真的不想再去公司任职了，虽然在经济上可能会有点压力，不过我还是喜欢做一个自由的程序员，认真地做一些自己想做的东西。

布衣郎 2007-12-27 19:00 发表评论

jsf中的国际化，验证和转换

布衣郎 — Thu, 24 May 2007 05:26:00 GMT

这些东东，对于web框架来说，是必不可少的，来看看jsf是如何实现的。首先看一下国际化，默认的情况下，会选择默认的locale，以及相应的资源文件。当然可以通过以下方式进行配置：

<application>
<locale-config>
<default-locale>endefault-locale>
<supported-locale>ensupported-locale>
<supported-locale>essupported-locale>
locale-config>
<message-bundle>CustomMessagesmessage-bundle>
application>

资源文件，也是和其他web应用一致。

halloween=Every day is like Halloween.
numberOfVisits=You have visited us {0} time(s), {1}. Rock on!
toggleLocale=Translate to Spanish
helloImage=../images/hello.gif

如果需要在页面中使用相应的bundle，需要使用以下的标记：

<f:loadBundle basename="LocalizationResources" var="bundle"/>
<h:outputText value="#{bundle.halloween}"/>

当然这是使用默认的locale设置，如果想动态切换locale，目前我的处理方式是这样的：

<f:loadBundle basename="messages_#{localeBean.locale}" var="msg"/>

当然localeBean.locale的值是动态更改的，可以为en,zh_CN，等等。
个人觉得和spring 的web framework相比，没有spring的那么灵活，不过基本上都能解决问题，凑合着用吧。

如果想在代码中使用，还是需要使用以下方法：

public static String getMessageString(String name, Object params) {
    String str = "";
    FacesContext facesContext = FacesContext.getCurrentInstance();
    String bundleName = facesContext.getApplication().getMessageBundle();
    if (bundleName != null) {
        Locale locale = facesContext.getViewRoot().getLocale();
        ResourceBundle bundle = ResourceBundle.getBundle(bundleName,
            locale, getCurrentClassLoader(params));
        str = bundle.getString(name);
    }
    return str;
    }

对于验证机制，基本的接口为Validator,只有一个方法validate。通常的验证机制，都是通过服务端来实现。如果想支持客户端支持，估计还得自己写一套接口去替换。不过看了其生命周期，觉得很难实现，除非脱离其生命周期。当然，这些使用ajax来处理，可能会减少服务端的通信负担。
其默认的验证实现，包括以下几个：

   DoubleRange：<f:validateDoubleRange>
      Length：<f:validateLength>
      LongRange：<f:validateLongRange>

   从字面意思可以看出来。
   当然，每个组件都有默认的验证器required。只要设置其属性为ture，就会进行空值判断。

   对于组件来说，支持多个验证器。但是没有看到关联组件的验证器，需要自己实现。如password的是否一致

   类型转换，接口Converter，包括两个方法:

    public Object getAsObject(FacesContext context, UIComponent component,
                              String value);
    public String getAsString(FacesContext context, UIComponent component,
                              Object value);

前者转化为对象，后者为用于页面输出。
在进行验证前，都会先进行值转换。
对于转换,内部已经提供了基本类型的实现，包括数字，日期，boolean型。
当然Converter另外一个功能，就是提供格式化输出，支持NumberFormat和DateFormat的输出：
包括：和其样式，完全采用相应的java样式。

布衣郎 2007-05-24 13:26 发表评论

velocity 二开发篇

布衣郎 — Wed, 16 May 2007 23:34:00 GMT

摘要: 先来看看velocity是怎么工作的？

在应用中使用velocity，一般需要以下的几个步骤：

* 初始化Velocity,可以使用单例，或者运行期实例
* 创建context对象，用于包括相应的变量
* 在context中增加相应的数据
* 选择模板
* 合并模板，产生输出

阅读全文

布衣郎 2007-05-17 07:34 发表评论

关于velocity 一语法篇

布衣郎 — Mon, 14 May 2007 00:30:00 GMT

    一个古老而又强大的模版引擎。在模版引擎中,velocity中，应该属于最常用的，不管是在maven的项目模版，还是在源代码输出，甚至直接网页输出中，都可以看到其身影。当然，最近的freemarker大有平分天下之意。
   以前的时候，曾用velocity设计过一个自动代码的项目，在用的过程中，享受了其简单而又灵活的功能。后来由于，自动代码的项目一直没有什么进展，也就很少去关注velocity。这段时间，被jsf搞得焦头烂额，最后想起了velocity，看看能不能用其来实现替换jsf的标记库功能。于是又复习了一遍velocity。
   先来看看velocity的语法：vtl也就是velocity的基本语言.用过脚本语言的，对于这个应该会很容易上手，其实，基本上，语法可以分为变量和关键词。先来看看变量，变量使用$作为开头符号，$a 和${a}是一致的。类似于jstl中的变量定义。在模版中声明一个变量是很容易的，使用set关键字
   #set( $foo = "Velocity" )。对于velocity中，感觉比较灵活的就是变量中，可以直接使用方法，和javabean属性一样方便使用：
   对于javabean 支持内置属性，如下：$customer.Address，$purchase.Total，$customer.Address.phone。不过好像不支持map语法，如：
a["key"]这种写法。但是可以使用方法代替：a.get("key")。而使用了方法，感觉就在使用java代码一样方便。当然变量中支持简单的表达式计算：$a+1等等
   有一点需要注意的是，如果变量没有解析，还是会输出$a这个变量，而不是空白，或者报错，这一点，不知道是方便还是不方便。
   语法中另外一个，就是关键字了，关键字使用#开头。
   其关键字也不多，只有少数的几个，但是已经足够用了。如前面的声明变量：#set
   #if #elseif #else #end 这是最常用的条件判断，每个判断使用#end结尾
   #if($a==1)true enough#{else}no way!#end

   #foreach() #end用于循环输出
   #foreach( $key in $allProducts.keySet() )

Key: $key -> Value: $allProducts.get($key)

   #end

   #include，用于包括一些资源文件，当然include是不会去解析资源文件，这和#parse不同
   #include( "one.txt" )

   #parse，用于解析并且包括相应的资源文件
   #parse( "me.vm" )，和主文件共享相应的Context

   #stop,用于停止执行解析，并返回，主要用于调试功能。

   基本上，使用以上的语法，可以定义出任何的模版了。当然，为了简化模版的定义，velocity特意推出了#macro这个强大的功能.
   #macro，类似于宏定义，用于自定义相应的标记。
   如下定义了一段宏，用于输出表格中的列表
   #macro( tablerows $color $somelist )
    #foreach( $something in $somelist )
        $something
    #end
   #end

   在模版中，只需要使用#tablerows($color $somelist)就可以取代里面的代码了：
   #set( $greatlakes = ["Superior","Michigan","Huron","Erie","Ontario"] )
   #set( $color = "blue" )

     #tablerows( $color $greatlakes )

而且#macro 支持内嵌语法，所以对于模版的定义，就变得更加的灵活而简单了。

布衣郎 2007-05-14 08:30 发表评论

关于jsf 的标记库

布衣郎 — Wed, 09 May 2007 12:33:00 GMT

对于标记库，不想再说些什么了。jsf可能最大的毛病都在这个标记库上面，首先定义的标记在jsp中，并不起到相应的输出功能，而只是用来增加相应得组件。在jsf中，最上层的组件为UIViewRoot，基本上所有的操作都是需要围绕着此组件。而标记库的存在，只是为了简化相应的操作。如下的标记：

<f:view>
    <h:form>
     <h:panelGrid>
        .
    h:panelGrid>
       h:form>
f:view>

其实对应的java代码，如下：

FacesContext context = FacesContext.getCurrentInstance();
UIViewRoot root = context.getViewRoot();
HtmlForm form = new HtmlForm();
HtmlPanelGrid grid = new HtmlPanelGrid();
form.getChildren().add(grid);
root.getChildren().add(form);

也就是说没有标记库，我完全可以使用java代码完成。
那么标记库的存在到底有没有意义，意义可能就在于简化相应的操作，想想html的属性是比较多的，如果每个都要用java代码去控制，那么可能对于应用来说，显得很不灵活，因为改代码毕竟没有改jsp来的快。而且代码需要重新编译。所以jsf的标记库存在也是有点意义的。
可是，现在的问题是，由于jsf本身就是规范，其实现也就会各有不同，对于每种实现都会带有自己的那一套标记库，随着标记库的增加，对于使用者来说，也是不堪忍受的重负。所以，有些时候，如果需要动态做一些配置，那么还是丢弃标记库，用java代码来完成吧。当然facelets，提供了一种方式，用于很灵活的扩展多个标记库，可是，看着那么多的标记，总是还有些头疼。

其次，对于标记库来说，各个标记库的不兼容也是一个很大的问题。就拿jstl和jsf来说，jstl的变量声明，在jsf中肯定是没有办法解析的，同样jsf中的变量，在jstl中也不能认识。我指的是页面声明的变量，而不是session变量，如下的例子：

<h:dataTable styleClass="table-background"
                                 rowClasses="table-odd-row,table-even-row"
                                 cellpadding="3"
                                 value="#{recordBean.records}"
                                 var="record"
                                 binding="#{recordBean.recordData}">
   <c:if test="${record}">

   c:if>
h:dataTable>

在dataTable中声明了变量record，但是在jstl中是不会认识的。
可能这个问题，facelets已经解决了，主要facelets把所有的Elcontext中的变量都结合在了一起，使用自身的FaceletsContext。
不过，如果我只是需要简单的功能，还需要使用facelets，那么也就有点大材小用了。况且facelets也只是提供了类似tiles的功能。
最后，想说的是，虽然jsf目前的ide支持，比其他框架多多了。可惜，人家都是建立在相应的标记库上的，如果你定义了自己标记库，人家不一定会认识。所以标记库的存在，对于jsf来说，也许并不一定是好事情，可能sun觉得如果把jsp抛弃了，有点可惜。所以在升级jsf的同时，也升级了相应得jsp规范。
个人觉得，也许模版技术，可能也会是一种选择，看看velocity和freemarker，觉得其比jsp有优势多了。

布衣郎 2007-05-09 20:33 发表评论

关于jsf 生命周期

布衣郎 — Fri, 04 May 2007 07:44:00 GMT

    这是jsf 的分析系列第三篇，随着不断的深入，jsf的设计变得越来越清晰。当然，在目前的规范中，jsf还是很不完善的，这也就导致了为什么jsf还是不能成为目前的主流框架。先不去谈论这些弊端，还是先看看一下jsf具体是如何运作的。
    对于jsf规范，个人觉得和其他框架相比，最大的区别，可能在于jsf划分了web 请求的生命周期。like ejb一样，web 请求也是有生命周期的。虽然，在其他的框架中，也可以看到相关的生命周期，但还是没有jsf划分的清晰。也许，这也是jsf的一大特色。
    对于生命周期的执行，所有的操作都归结到Lifecycle这个接口。接口包括了两个主要的方法：
    public abstract void execute(FacesContext context) throws FacesException;和
    public abstract void render(FacesContext context) throws FacesException;
   前者是用来执行各个生命周期的阶段，也就是除了render之外的其他五个阶段，而且是按照相应的顺序执行。而render，是执行最后一个阶段，展示页面。可能有人不太理解，为什么不把两个方法合并成一个方法，刚开始，我也是这么认为。既然已经定义了相应的Phase，何必要把最后的render过程分离出来。看了sun 的RI实现类，发现在render之前需要进行context.getResponseComplete()判断，可能规范中，认为render是必须要执行的阶段，其他的阶段可以跳过，所以分离了相应的方法,同时在执行前,为了避免重复输出,需要对render过程进行特殊的处理.
   规范中定义了6个阶段，从下面的流程图中可以看到。

简单介绍一下每个阶段的工作：

RESTORE_VIEW：查找原有的view ，恢复原有的状态，如果没有，则调用ViewHandler.createView，如果为post操作，则按照顺序执行各个阶段。
否则执行RENDER_RESPONSE阶段。
APPLY_REQUEST_VALUES：读取客户端参数，处理各个组件的processDecodes方法，内部调用decode方法，由Renderer执行decode方法
PROCESS_VALIDATIONS：执行组件的processValidators方法，对于UIInput执行validate方法，用于绑定值，调用convert,和validate
UPDATE_MODEL_VALUES:执行组件的processUpdates方法，对于UIViewRoot，执行broadcastEvents和notifyPhaseListeners
所有的UIInput,执行updateModel方法。
INVOKE_APPLICATION：调用UIViewRoot.processApplication方法。这一过程主要读取相应的action配置，如果存在action，则调用action，也就是调用应用逻辑。在执行完相应的逻辑后，查询action是否返回值，如果有，由navigationHandler去读取下一个view id。
RENDER_RESPONSE：展示view，调用ViewHandler.renderView,展示view。

每个阶段定义定义的都比较清晰，有一点需要注意的是，在处理请求时，并不一定会执行每个阶段，可能其中会直接跳到最后的render response阶段。举例来说，如果validator时，存在错误信息，那么就会直接到render response阶段，而下一个阶段不会执行。

布衣郎 2007-05-04 15:44 发表评论

了解jsf的架构二

布衣郎 — Wed, 25 Apr 2007 08:33:00 GMT

    接上一篇内容。这次主要分析一下jsf的相关组件包，也是jsf和structs主要不同的地方。jsf 规范中，对于组件的设计，和其他组件架构一样，分离表现层和模型层。对于组件的render由具体的Renderer来处理，这也达到了Model和View分离的原则。
    component:所有的基本组件都在其中，如下的主要类图，对于各个组件就不一一详细介绍了。主要介绍一下几个接口：

StateHolder：用于表示在请求之间需要保存相应的状态信息,必须实现saveState和resotreState方法。
ValueHolder：用于支持本地值的保持，用于访问model数据，通过表达式，支持转换。
EditableValueHolder：用于表示那些可以编辑的组件值
ActionSource：由UIComponet实现，用于作为ActionEvent的事件源，支持默认的ActionListener调用
ActionSource2：这是最近的规范中增加的，提供了对于MethodExpression的支持。
ContextCallback：用于组件执行相应的回调
NamingContainer：标志接口，表示容器组件

    convert:包括了主要的Convert接口，以及内置的Convert实现类，主要的作用用于在页面值绑定时，进行类型的转换工作
    validator：主要的验证包，定义了通过的Validator接口，以及简单的几个验证类。默认情况下，jsf都是进行服务端验证，如果想需要客户端验证，暂时从规范中，还没有找出相应的解决方案。不过现在已经是Ajax时代了，使用异步的传输，从效果上已经接近于客户端之间验证。
    event:主要的事件体系。个人觉得jsf的事件体系还是比较弱的。和强大的Swing事件体制相比，那简直差远了。而且jsf默认使用一个ActionListener来委派所有的客户端动作触发。大多数的调用都是使用MethodExpression来进行。
    model:只是加强了对于DataTable的支持，以及SelectItems。
    render：主要的展示包，当然只是提供规范，具体由实现类提供。对于Renderer，都需要一套RenderKit.而RenderKit由RenderKitFactory管理。ResponseStateManager，作为StateManager的帮助类，进行主要的State操作。
    基本上，规范也就这么些东东。从整体来看，并不算太复杂。可惜现在的jsf实现实在太多了，而且各个实现并不一定兼容，导致了jsf世界的庞大。

布衣郎 2007-04-25 16:33 发表评论