`

WebWork深度探索之Session

阅读更多

        昨天上午刚写完WebWork的Pitfall[1],特别提到了文档的问题,结果下午就深受其害了。其实,我想做的功能很简单,就是在页面上判断一下某个字段在Session中是否存在,如果存在则显示内容A,否则就显示内容B。原本以为可以很快的找到这个方面的参考资料,结果是找了一个下午都没有从官方文档中找到相应的说明,最终还是通过Mail-List Archive找到了解答。
        由于WebWork对request,parameter,Session和Application都进行了封装,将这些隐含的对象封装成了相应的Map,如RequestMap,ParameterMap,SessionMap和ApplicationMap,而这些Map就组成了ActionContext,因此我们通常都不再需要与request,session这些底层的对象打交道了,这也是我一开始觉得迷惑的地方,因为我找不到Session了。事实上,对于SessionMap的处理即是对Session的处理了。我们可以通过ActionContext的静态方法getContext返回一个ActionContext的实例,然后再调用其getSession方法获得SessionMap,接着就可以利用put和get方法对session进行读写的操作了。
        而在页面上,我们可以通过以下的方式对session进行操作:

<webwork:property value="#session.name" />

        #session.name表示从SessionMap中取得与"name"这个key对应的对象,实际上是调用了如下的statement:ActionContext.getContext().getSession().get("name"),并且进行了类型的转换。又如:     

<webwork:property value="#session.player.name" />

        则是在SessionMap中获得了Player对象之后,并调用类Player的getter方法:getName()获得name属性。
        简而言之,为了能够降低与部署环境的耦合程度,WebWork将Servlet的隐含对象进行了封装,这在很大程度上简化了开发的工作。而且WebWork也提供了类ServletActionContext,我们通过这个类中的getRequest方法获得原始的HttpServletRequest,然后就可以对request和session这些底层对象进行操作了。但是,一般情况下,利用ActionContext.getSession()可以完成几乎所有的工作了,我们又为什么要去碰那些底层的东西呢?因此我们应该优先考虑使用SessionMap,而不是底层的session。
        另外一个需要注意的问题,就是SessionMap和隐藏对象session的作用域是不同的。也就是说,通过 ActionContext.getContext().getSession().put("name","Fantasy Soft"),往SessionMap中写入了与"name"这个key相对应的内容,但是在页面上通过session.getAttribute("name")得到的将会是null。
        最后,我不得不再次说一下WebWork的文档,由于文档也是开源的,是依靠热心的开发人员去撰写的,因此质量与数量上都与WebWork本身相去甚远。尽管酒香不怕巷子深,但是这是一个注意力经济的时代,信息匮乏造成的受注意程度降低会让自己处于一个不利的位置。
       
        [1] WebWork深度探索之Pitfall

分享到:
评论
1 楼 thebye85 2009-05-09  
引用

另外一个需要注意的问题,就是SessionMap和隐藏对象session的作用域是不同的。也就是说,通过 ActionContext.getContext().getSession().put("name","Fantasy Soft"),往SessionMap中写入了与"name"这个key相对应的内容,但是在页面上通过session.getAttribute("name")得到的将会是null。

这个可以访问的

相关推荐

Global site tag (gtag.js) - Google Analytics