<h1>firebody</h1>

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://firebody.blogbus.com/logs/324155.html

1)拦截请求，取出URI（String），从session中取出user
2）根据URI取出(long)resourceId.－－－－》（需求暗示URI与resource由对应关系）
 resource=webApplicationContext.getBean("permManager").getResource(actionName);
 如果rsource为空，说明这个action没有加入权限点，新增这个权限点后返回，继续验证（肯定失败，因为权限点没有分配给角色）；
 如果resource不为空，则需要进一步验证。
3)调用webApplicationContext.getBean("permManager").hasResource(resourceId,userId);
4)如果验证通过，forward
5)如果验证失败，输出相应错误信息。

可以断定：resource与action是一对多的关系。我们可以将actionName与resource对应即可。

值得注意的一点是：角色的意义。不同的场合有不同的意义。
例如:文章管理－－似乎可以作为一个角色。照着这个理解往下走：文章管理包括
文章发布权限点，文章编辑权限点。但是在我的例子中，一个action对应一个权限
点（可以让一个权限点包含多个action吗？不大妥当，难以管理！）。文章编辑可
以仅仅用一个action来完成所有的业务逻辑吗？有点难度。不过确实可以，直接
传输XML文件到客户端，让客户端第一次请求就得到所有信息，然后交互就利用js
在客户端完成，知道最后客户提交数据。这样的话，就大大简化（减少）action类。
客户肯定不希望一步一步的往下走，而是一次清晰的完成它想做 的事情，从这个
意义出发，如果不做好人性化的界面，那么产品就没有出路，甚至是垃圾。让客户
一次清晰的完成他想做的事情，就是我以后做界面的目标。
我晕倒，说着说着，就大聊特聊人性化界面了。我们转到正题：角色在我的应用中
不能简单的理解为一个管理类，而是看一个具体意义的业务需要一个还是多个action
交互才能完成，如果一个具体业务仅仅需要一个action就能做完所有的逻辑，毫无疑问，
这是一个权限点。但是一个具体业务如果不得不需要多个action才能完成的话，按照
角色与权限点的对应关系逻辑，毫无疑问，这个具体的业务就需要作为一个role（
角色）来定义拉。这时候，就有点胡涂了，一些具体业务既可以做为权限点，又可以做
角色。显然，我们可以统统将具体的业务（用例）作为一个角色来定义，这个用例的角色
可能需要一个或者多个权限点。
好了，分析结束，就是这样干的。
但是在前台界面，作为人性化界面的设计就有点麻烦，看看下面：

文章管理
|
---文章发布
|
---文章编辑
栏目管理
|
－－栏目管理
类别管理
|
---类别管理
用户管理
|
----用户管理
权限管理 （权限点不能自己手工增加，而是由拦截器自动增加）
|
----增加角色
|
---编辑角色
|
----给角色分配权限点
|
----给用户分配角色

现在问题来了，前台界面需要根据不同用户提供相应的菜单，那么怎么做到这个
动态菜单呢？就是将这个用户的所有角色数据下传到客户端。然后根据角色的type
归类到相应的type中去，比如这样指定：
if(role.type.equales("文章管理") )
 //归类到文章管理