昨天上午刚写完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