关于Struts2里使用EL或JSTL

最近在公司里做一些Java Web开发的培训,同时对已经做的一些工程做一些ReView,现在的工程里,工程师直接使用JSTL取得Action里的属性,这个用法我以前到真的没有用过,因为在我印象中,Struts2的这些Action属性,应该是在ValueStack中,而在某些情况下,从ValueStack取值是件挺麻烦的事情,在做天乙社区8时,我就参考Struts2的标记库,自己扩展标记库,从而取得ValueStack里的值,而JSTL应该是从Page、Request、Session和Application里顺序取值,莫非Struts2将ValueStack里的值也放入了Request?同时我们直接用EL标签也直接取出了Action的属性值,莫非真的放入了Request?但是打开Struts2的Debug,发现Request里并没有值。

带着这个疑问,我Google了一下,很快找到答案:

提问:在Struts2中,如何使用JSTL来读取Action中的变量?

这是一个历史悠久的问题。因为事实上,很多朋友(包括我在内)是不使用Struts2自身的标签库,而是使用JSTL的,可能因为JSTL标签库比较少,简单易用的原因吧。

我们知道,JSTL默认是从page,request,session,application这四个Scope逐次查找相应的EL表达式所对应 的对象的值。那么如果要使用JSTL来读取Action中的变量,就需要把Action中的变量,放到request域中才行。所以,早在 Webwork2.1.X的年代,我们会编写一个拦截器来做这个事情的。大致的原理是:在Action执行完返回之前,依次读取Action中的所有的变 量,并依次调用request.setAttribute()来进行设置。具体的整合方式,请参考以下这篇文档:http://wiki.opensymphony.com/display/WW/Using+WebWork+and+XWork+with+JSP+2.0+and+JSTL+1.1

不过随着时代的发展,上面的这种方式,已经不再被推荐使用了。(虽然如此,我们依然可以学习它的一个解决问题的思路)目前来说,自从 Webwork2.2以后,包括Struts2,都使用另外一种整合方式:对HttpServletRequest进行装饰。让我们来看一下源码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
 public class StrutsRequestWrapper extends HttpServletRequestWrapper {
 
     /**
      * The constructor
      * @param req The request
      */
     public StrutsRequestWrapper(HttpServletRequest req) {
         super(req);
     }
 
     /**
      * Gets the object, looking in the value stack if not found
      *
      * @param s The attribute key
      */
     public Object getAttribute(String s) {
         if (s != null && s.startsWith("javax.servlet")) {
             // don't bother with the standard javax.servlet attributes, we can short-circuit this
             // see WW-953 and the forums post linked in that issue for more info
             return super.getAttribute(s);
         }
 
         ActionContext ctx = ActionContext.getContext();
         Object attribute = super.getAttribute(s);
 
         boolean alreadyIn = false;
         Boolean b = (Boolean) ctx.get("__requestWrapper.getAttribute");
         if (b != null) {
             alreadyIn = b.booleanValue();
         }
 
         // note: we don't let # come through or else a request for
         // #attr.foo or #request.foo could cause an endless loop
         if (!alreadyIn && attribute == null && s.indexOf("#") == -1) {
             try {
                 // If not found, then try the ValueStack
                 ctx.put("__requestWrapper.getAttribute", Boolean.TRUE);
                 ValueStack stack = ctx.getValueStack();
                 if (stack != null) {
                     attribute = stack.findValue(s);
                 }
             } finally {
                 ctx.put("__requestWrapper.getAttribute", Boolean.FALSE);
             }
         }
         return attribute;
    }
}

看到了嘛?这个类会在Struts2初始化的时候,替换HttpServletRequest,运行于整个Struts2的运行过程中,当我们试 图调用request.getAttribute()的时候,就会执行上面的这个方法。(这是一个典型的装饰器模式)在执行上面的方法时,会首先调用 HttpServletRequest中原本的request.getAttribute(),如果没有找到,它会继续到ValueStack中去查找, 而action在ValueStack中,所以action中的变量通过OGNL表达式,就能找到对应的值了。

在这里,在el表达式广泛使用的今天,JSTL1.1以后,也支持直接使用el表达式。注意与直接使用struts2的tag的区别,这里需要使用el的表示符号:${}

例如:${user.name}, <c:out value=”${department.name}” />

原来是这样,学无止境啊,很多东西需要仔细去研究。

PHP框架选择

离最初用PHP编程序已经有8、9年时间了,后来这6、7年的时间一直研究Java,对PHP有些生疏了,但PHP的生命力却依旧顽强,对于面向Web开发时Java的繁琐,我最近又将注意力集中到了PHP上,但已经习惯了Struts这样的MVC框架,我也要寻找一个适合的PHP MVC框架,选择的标准有几个:1、性能;2、易用性;3、文档;4、长期支持度

我最开始看了Zend Framework,Zend的东西,毕竟带有官方特性,他的framework应该是代表着主流,看了之后,Zend Framework可以说是纷繁复杂,但是面面俱到,Web应用方面的问题基本都可以解决,我唯一担心的就是性能,虽没有做过测试,但也确实担心。

后来有一天在JavaEye上逛,看到一篇帖子《PHP框架的繁荣是正确的发展方向吗?》,讨论了PHP的运行机制、与ROR的比较、性能等等,非常热闹,同时也列举出了一些PHP的框架,特别是一些性能比较,让我很吃惊,CakePHP、Symfony可以不用考虑了。

接下来我看了看CodeIgniter,感觉不错,简单,相比Zend Framework要简单得多,大多数问题也都能解决,性能在一些资料描述中也表现的尚可(比Zend Framework要快几倍),而且其文档比较细,学习起来不难,后来又发现了Kohana,Kohana是从CodeIgniter衍生出来,由于CodeIgniter是兼容PHP4和5的,而Kohana只支持PHP5,是完全的OO方式,其文档并还没有仔细研究,看到了一个比较的文章《Notes on Choosing a PHP Framework: A Quick Comparison of CodeIgniter and Kohana》,看上去Kohana有些特性还是很优秀的,但不知道Kohana社区对于这个开源产品的支持有多好。

后来又看到文章《Performance of Yii》,发现Yii这个框架的性能更强劲啊,比CodeIgniter还要好几倍,不可思议,看了看Yii的文档,它也是完全OO的,要PHP5以上,核心应该也比较简单,能保持比较好的性能,但我觉得它的Guide文档比较粗,学习起来似乎要费点功夫,其性能应该是我最感兴趣的地方。

再说说国内的PHP框架,在JavaEye的文章里,QeePHP的作者也在推荐自己的框架,简单测试下比Yii还要快,好NB啊,但从社区反应出来其文档不够详细,其代码我也没有细看,似乎和Yii有很多相近的地方,另一个国内的PHP框架ThinkPHP文档比较详尽,但没有测试报告,不知道性能如何,而且在PHPChina的社区里和QeePHP有激烈的争论,挺有意思的。

看了一大圈,我也没有决定采用何种PHP的框架,他们各有长处,也各有缺陷,但综合考虑,我还是应该会在CodeIgniter、Kohana和Yii中选择最终的方案。