- 浏览: 718887 次
- 性别:
- 来自: 上海
-
最新评论
-
A741841403:
附件怎么看不到了呢?
介绍一个PDF的生成方案 -
chunguang_yao:
写得非常好
《Struts2技术内幕》 新书部分篇章连载(一)—— 如何学习开源框架 -
su_chunlong:
rrredriver 写道极赞的文章,感谢楼主!有一个问题想请 ...
SpringMVC深度探险(三) —— DispatcherServlet与初始化主线 -
qq_32671287:
...
SpringMVC深度探险(一) —— SpringMVC前传 -
shenghuorulan:
看的好爽,可不可以这么笼统的概括一个框架的学习过程1,框架要解 ...
SpringMVC深度探险(二) —— SpringMVC概览
背景
Struts2已经日益成为Web层比较主流的开发框架,它来源于Webwork2,是一个非常优秀的MVC框架。在Webwork2设计之处,Annotation和Ruby on Rails还没有像现在那么火,所以整个框架在配置方面还是沿用了Web框架惯用的XML作为主要的配置方式。
随着时代的发展,对于Web程序员来说,如何简化配置成了一个很重要的课题。在这方面,Struts2也有一些探索。在Struts2的官方网站上,我们可以找到一些优秀的plugin来做这些工作:
http://cwiki.apache.org/S2PLUGINS/codebehind-plugin.html
http://cwiki.apache.org/S2PLUGINS/smarturls-plugin.html
LightURL的目的是为了吸取这些优秀的plugin的优点,并支持更方便的配置方式。
版本提示
目前LightURL是基于struts2.0.X的版本写出来的。由于struts2.1.X尚属于beta版本,而且与之对应的XWork在IoC这块做了重大的修改,所以,我也暂不打算支持到struts2.1.X。如果使用struts2.1.X结合lighturl发生问题的朋友,请退回到struts的稳定版本。
安装
1. 将struts2-lighturl-plugin.jar加入到classpath下
2. 配置你的web.xml
3. 需要指定你的action package所在位置和一些基本配置
这一步一般在struts.properties中完成。你可以建一个struts.properties的配置文件,并放到classpath下,并指定如下配置
在完成以上的步骤后,lighturl的所有配置即告完成,现在你已经可以使用所有lighturl所提供的特性。
Namespace, ActionName和URL映射
lighturl所提供的最基本的特性是根据你的Action所在的package,确定namespace和actionName,并进行对应的URL映射。
举例说明,你在上面所讲述的struts.properties中,已经指定了你的action package
那么,如果你有以下的Action类,那么lighturl将根据如下的规则来确定每个Action类所对应的namespace,actionName和url映射关系
1. 根据lighturl.action.packages的配置的package到你的Action类的相对package来确定namespace,如果其中有驼峰法命名,那么转化成"-"连接的单词
2. 将Action类的类名转化成actionName。如果碰到的Action类以"Action"结尾,则去掉末尾的"Action",如果其中有驼峰法命名,那么转化成"-"连接的单词
3. 将namespace与actionName拼起来,就成构成映射到具体Action类的url
上面的这种URL匹配方式,我称之为:package匹配
特殊形式的URL
应该说根据package来进行Action映射,可以解决绝大多数从url到action的映射配置问题。不过有的时候,我们可能需要支持一些特殊形式的url。LightURL在默认情况下,支持下列2种特殊形式的URL
1. 支持将名为Index的Action直接映射到package上
这种匹配我称之为:Namespace匹配。这一个特性很直观。如果你在某个Action的package下面有一个名为Index的Action类,那么如果你直接访问这个package,那么你可以访问到这个类:
2. 支持类似: /entity/${id}形式的URL
这种匹配我通常称之为:entity匹配。这个特性也比较简单,如果你有某个entity,并且在你的Action package下有一个与entity同名的package。同时在这个package下有一个叫View的Action,那么上述形式的URL会被映射到该Action。
你可以通过在struts.properties中指定你entity所在的package来对哪些url可以具备这些特性,如果你输入的url不在你所指定的package中含有entity,那么这个url将无法被识别。
针对有些情况,数据库的主键可能不是数字。此时,你可以通过自己实现com.demo2do.lighturl.config.EntityPrimaryKeyIdentifier的接口来指定你的url中id具备什么特点。默认的实现是将主键识别为数字。
不过一般而言,典型的entity匹配是无法满足我们的要求的。因为我们往往不会针对某个entity直接为action建立package,而是会对某个entity,对应到某个Action,它位于某个具体的package。所以针对这样的需求,我对entity匹配做了一定的扩展:
也就是说,某个具体的package中,名字为View的Action,会对应到类似相同package下增加${id}的url。
使用Annotation来指定映射
除了上述这些基本特性以外,还可以通过Annotaion来指定URL映射。目前情况下,LightURL所支持的Annotation有两种类型:
1. URL完整匹配
URL完整匹配是指如果某个url完整匹配于Annotation中所指定的内容,那么这个URL将被映射到Annotation所在的Action类的method
例如,上述的Action类有一个Annotation,那么这个Action和method将被映射到对应的URL:http://host:port/app/all/search-user。
注意,此时,虽然从url上来看,这是一个没有什么规则的url,但是其所对应的namespace和actionName还是根据com.demo2do.lighturl.action.user.Search来进行计算的。
2. URL Template
URL Template是指,url可以匹配Annotaion中指定的某种URL Template,并将其中的可变部分作为参数映射到Action中。
在上述的例子中,可以发现,在Annotation中所指定的内容是一个URL Template,如果你有一个url,可以匹配上面的URL Template,那么url将匹配到这个Action的method,并且将对应位置的值注入到Action中的同名参数中。
不仅如此,LightURL还能够支持AntPath的URL匹配。这样可以通过书写/blogs/common/*或者/blogs/**来匹配多个不同的URL映射。
针对上面的例子:
http://host:port/app/blogs/2008/08/07将被映射到这个Action的execute,并且2008,08和07分别映射到year,month和day中。
http://host:port/app/blog/2345/edit将被映射到Action的edit方法,并且2345映射到id中作为参数
http://host:port/app/blogs/common/abcd将被映射到Action的common方法。
URL的匹配顺序与重复配置的校验
在上面的例子中,介绍了那么多的url映射到Action中的方式。他们之间可能会出现冲突,有些冲突,LightURL会在系统启动时为你检查出来,并强制要求你纠正它,而有些冲突,则通过优先级匹配的方式进行。
下列冲突将被认为是你必须在系统启动前就进行纠正的:
1. Annotation中定义的URL Template互相之间冲突
例如:/blogs/${year}/${month}/${day}和/blogs/${category}/${id}/edit就是冲突的。
2. Annotation中定义的URL Template与其他Annotation中定义的完全匹配URL冲突
例如:/blogs/${year}/${month}和/blogs/category/index就是冲突的。
3. Annotation中定义的URL Template与形如/entity/${id}的url定义冲突
例如:/user/${id}形式的Annotation定义可能会与系统默认支持的冲突。
在其他情况下,如果你定义的URL映射互相直接有冲突,那么LightURL将根据某个顺序进行URL匹配,并找到第一个匹配的映射方式,然后放弃查找。这个顺序为:
1. 首先进行Namespace匹配,如果url恰好能匹配某个namespace,并且其对应的package下有Index作为Action,那么直接进行匹配。
2. 其次查看所有的Annotation定义中,是否存在完整的URL匹配,如果找到,那么进行直接匹配。
3. 接着进行package匹配,将url分解成相应的namespace和actionName,与已有的配置进行匹配,如果找到,那么直接匹配。
4. 然后进行entity匹配,看看url是否形如:/entity/${id},如果是,那么直接匹配。
5. 最后进行Annotation定义的Url Template匹配。
如果所有的五种情况都无法进行匹配,那么这个URL将无法被LightURL识别,继续交由Struts2进行后续处理。
上面所描述的内容都是Url到Action的映射。下面的部分,描述的是如何在Action执行完毕之后,转到相应的结果view。
Codebehind
LightURL支持codebehind。有关codebehind的相关知识,可以参考struts2的相关文档:
http://struts.apache.org/2.x/docs/codebehind-plugin.html
有了codebehind的支持,那么从Action转到类似jsp,ftl或者vm的view层组件就不需要任何配置,只要符合一定的命名规范,就可以直接进行转向。
在这里,LightURL不仅实现了Codebehind的所有功能。而且,LightURL还对Codebehind的规则做出了扩展。
Codebehind在寻址JSP等资源时,顺序按照以下的规则进行:
1. /namespace/actionName-<resultCode>.<ext>
2. /namespace/actionName.<ext>
而LightURL在寻址JSP等资源时,增加了一定的规则,并且按照如下顺序进行:
1. /namespace/actionName-<resultCode>.<ext>
2. /namespace/<resultCode>.<ext>
3. /namespace/actionName.<ext>
4. /namespace/namespace-actionName-<resultCode>.<ext>
5. /namespace/namespace-<resultCode>.<ext>
6. /namespace/namespace-actionName.<ext>
这样一来,大家就有更加宽广的选择范围,进行默认资源的寻址匹配了。
ResultCode的识别
但是在很多情况下,我们需要的是全方位的Result类型的支持。例如,有的时候我们需要返回JSON Result,有的时候,我们可能需要Redirect到一个新的Action。此时,我们不得不为此增加一些配置,或者借助Annotation来完成。
为此,LightURL提供了一种根据ResultCode进行识别的命名方式来匹配你所指定的Result。
以JSON Result为例,你可以这么写:
在这里,你可以发现,resultCode变成了j:user。那么此时,LightURL会将这个resultCode识别成:请返回JSON Result,并且JSON的Result的root为user对象。
再例如:
在这里,"r:/user/add-user"会被识别成:请返回Redirect Result。Redirect的URL为/user/add-user。
LightURL默认情况下,实现了对Redirect Result和JSON Result的ResultCode识别,并将他们的前缀分别定制为:"r:"("redirect:")或者"j:"("json:")。
当然,你可以根据你自己的情况,实现你自己的ResultCode的识别程序,你只需要实现com.demo2do.lighturl.result.ResultCodeConfig接口即可。并在struts.properties中指定你希望LightURL进行ResultCode匹配的顺序。
这样,LightURL会根据你所指定的顺序,依次进行ResultCode的匹配,直到找到第一个匹配的Result Type为之。
当然,默认情况下,LightURL的匹配顺序为:
codebehind -> 你自定义的ResultCode识别实现 -> json -> redirect
有无数人问我这个问题。难道大家都不仔细阅读我的说明嘛?
LightURL支持codebehind。有关codebehind的相关知识,可以参考struts2的相关文档:
http://struts.apache.org/2.x/docs/codebehind-plugin.html
有了codebehind的支持,那么从Action转到类似jsp,ftl或者vm的view层组件就不需要任何配置,只要符合一定的命名规范,就可以直接进行转向。
就算不仔细阅读我的说明,struts2的文档总该看一下吧。
开发环境中配置一个debug拦截器,在每个请求的时候console输出被调用的action以及其他调试信息(request parameter等),方便进行查找
配合Eclipse或者NetBeans等IDE打开文件特性,可以直接点击console输出打开对应的文件。
struts2.1.2只是增加了annotation功能,但是不支持类似url template和某些特殊的url映射。
前几天有一个朋友向我指出LightURL的一个问题,这也可能是很多CoC存在的问题。在使用xml配置的年代,需要根据URL来找一个Action相对比较方便,因为只要在一个文件中进行查找就好了。但是使用CoC之后,并没有一个具体的文件来记录这些对应关系,所以想查找这样的对应关系非常的困难。
Rails的routes.rb就是描述URL映射的,rails也带了rake,一个命令就可以打印出来整个web应用的所有URL对应关系,所以查找不是问题。
struts2.1.2只是增加了annotation功能,但是不支持类似url template和某些特殊的url映射。
前几天有一个朋友向我指出LightURL的一个问题,这也可能是很多CoC存在的问题。在使用xml配置的年代,需要根据URL来找一个Action相对比较方便,因为只要在一个文件中进行查找就好了。但是使用CoC之后,并没有一个具体的文件来记录这些对应关系,所以想查找这样的对应关系非常的困难。
Struts2已经日益成为Web层比较主流的开发框架,它来源于Webwork2,是一个非常优秀的MVC框架。在Webwork2设计之处,Annotation和Ruby on Rails还没有像现在那么火,所以整个框架在配置方面还是沿用了Web框架惯用的XML作为主要的配置方式。
随着时代的发展,对于Web程序员来说,如何简化配置成了一个很重要的课题。在这方面,Struts2也有一些探索。在Struts2的官方网站上,我们可以找到一些优秀的plugin来做这些工作:
http://cwiki.apache.org/S2PLUGINS/codebehind-plugin.html
http://cwiki.apache.org/S2PLUGINS/smarturls-plugin.html
LightURL的目的是为了吸取这些优秀的plugin的优点,并支持更方便的配置方式。
版本提示
目前LightURL是基于struts2.0.X的版本写出来的。由于struts2.1.X尚属于beta版本,而且与之对应的XWork在IoC这块做了重大的修改,所以,我也暂不打算支持到struts2.1.X。如果使用struts2.1.X结合lighturl发生问题的朋友,请退回到struts的稳定版本。
安装
1. 将struts2-lighturl-plugin.jar加入到classpath下
2. 配置你的web.xml
<!-- Struts Filter --> <filter> <filter-name>struts</filter-name> <filter-class>com.demo2do.lighturl.LightURLFilter</filter-class> </filter> <!-- Struts URL Definition --> <filter-mapping> <filter-name>struts</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
3. 需要指定你的action package所在位置和一些基本配置
这一步一般在struts.properties中完成。你可以建一个struts.properties的配置文件,并放到classpath下,并指定如下配置
## action package config lighturl.action.packages=com.demo2do.lighturl.action ## action mapping implementation class struts.mapper.class=com.demo2do.lighturl.LightURLActionMapper ## default parent package lighturl.action.default.parent.package=lighturl ## define your entity package (optional) # lighturl.entity.package=com.demo2do.lighturl.entity
在完成以上的步骤后,lighturl的所有配置即告完成,现在你已经可以使用所有lighturl所提供的特性。
Namespace, ActionName和URL映射
lighturl所提供的最基本的特性是根据你的Action所在的package,确定namespace和actionName,并进行对应的URL映射。
举例说明,你在上面所讲述的struts.properties中,已经指定了你的action package
lighturl.action.packages=com.demo2do.lighturl.action
那么,如果你有以下的Action类,那么lighturl将根据如下的规则来确定每个Action类所对应的namespace,actionName和url映射关系
1. 根据lighturl.action.packages的配置的package到你的Action类的相对package来确定namespace,如果其中有驼峰法命名,那么转化成"-"连接的单词
- com.demo2do.lighturl.action.Index ----> /
- com.demo2do.lighturl.action.user.Search ----> /user
- com.demo2do.lighturl.action.blog.category.Index ----> /blog/category
- com.demo2do.lighturl.action.accoutDetail.View ----> /account-detail
2. 将Action类的类名转化成actionName。如果碰到的Action类以"Action"结尾,则去掉末尾的"Action",如果其中有驼峰法命名,那么转化成"-"连接的单词
- com.demo2do.lighturl.action.Index ----> index
- com.demo2do.lighturl.action.user.SearchAction ----> search
- com.demo2do.lighturl.action.blog.CategoryBlog ----> category-blog
3. 将namespace与actionName拼起来,就成构成映射到具体Action类的url
- http://host:port/app/user/index ---> com.demo2do.lighturl.action.user.Index
- http://host:port/app/blog/category-blog ---> com.demo2do.lighturl.action.blog.CategoryBlog
上面的这种URL匹配方式,我称之为:package匹配
特殊形式的URL
应该说根据package来进行Action映射,可以解决绝大多数从url到action的映射配置问题。不过有的时候,我们可能需要支持一些特殊形式的url。LightURL在默认情况下,支持下列2种特殊形式的URL
1. 支持将名为Index的Action直接映射到package上
这种匹配我称之为:Namespace匹配。这一个特性很直观。如果你在某个Action的package下面有一个名为Index的Action类,那么如果你直接访问这个package,那么你可以访问到这个类:
- com.demo2do.lighturl.action.Index ---> http://host:port/app/
- com.demo2do.lighturl.action.user.Index ---> http://host:port/app/user
- com.demo2do.lighturl.action.blog.category.Index ---> http://host:port/app/blog/category
2. 支持类似: /entity/${id}形式的URL
这种匹配我通常称之为:entity匹配。这个特性也比较简单,如果你有某个entity,并且在你的Action package下有一个与entity同名的package。同时在这个package下有一个叫View的Action,那么上述形式的URL会被映射到该Action。
- com.demo2do.lighturl.action.user.View ---> http://host:port/app/user/3456
- com.demo2do.lighturl.action.blog.View ---> http://host:port/app/blog/1113
你可以通过在struts.properties中指定你entity所在的package来对哪些url可以具备这些特性,如果你输入的url不在你所指定的package中含有entity,那么这个url将无法被识别。
针对有些情况,数据库的主键可能不是数字。此时,你可以通过自己实现com.demo2do.lighturl.config.EntityPrimaryKeyIdentifier的接口来指定你的url中id具备什么特点。默认的实现是将主键识别为数字。
不过一般而言,典型的entity匹配是无法满足我们的要求的。因为我们往往不会针对某个entity直接为action建立package,而是会对某个entity,对应到某个Action,它位于某个具体的package。所以针对这样的需求,我对entity匹配做了一定的扩展:
- com.demo2do.lighturl.action.user.admin.View ---> http://host:port/app/user/user/3456
- com.demo2do.lighturl.action.blog.category.View ---> http://host:port/app/blog/category/1113
也就是说,某个具体的package中,名字为View的Action,会对应到类似相同package下增加${id}的url。
使用Annotation来指定映射
除了上述这些基本特性以外,还可以通过Annotaion来指定URL映射。目前情况下,LightURL所支持的Annotation有两种类型:
1. URL完整匹配
URL完整匹配是指如果某个url完整匹配于Annotation中所指定的内容,那么这个URL将被映射到Annotation所在的Action类的method
package com.demo2do.lighturl.action.user; import com.demo2do.lighturl.annotation.Action; import com.opensymphony.xwork2.ActionSupport; /** * @author Downpour * */ public class Search extends ActionSupport { private static final long serialVersionUID = -1728616675239859226L; /* (non-Javadoc) * @see com.opensymphony.xwork2.ActionSupport#execute() */ @Override @Action("/all/search-user") public String execute() throws Exception { return super.execute(); } }
例如,上述的Action类有一个Annotation,那么这个Action和method将被映射到对应的URL:http://host:port/app/all/search-user。
注意,此时,虽然从url上来看,这是一个没有什么规则的url,但是其所对应的namespace和actionName还是根据com.demo2do.lighturl.action.user.Search来进行计算的。
2. URL Template
URL Template是指,url可以匹配Annotaion中指定的某种URL Template,并将其中的可变部分作为参数映射到Action中。
package com.demo2do.lighturl.action.blog; import com.demo2do.lighturl.annotation.Action; import com.opensymphony.xwork2.ActionSupport; /** * @author Downpour * */ public class Category extends ActionSupport { private static final long serialVersionUID = -1535992103374733252L; private Long id; private int year; private int month; private int day; /* (non-Javadoc) * @see com.opensymphony.xwork2.ActionSupport#execute() */ @Override @Action("/blogs/${year}/${month}/${day}") public String execute() throws Exception { return super.execute(); } @Action("/blog/${id}/edit") public String edit() throws Exception { return super.execute(); } @Action("/blogs/common/*") public String common() throws Exception { return super.execute(); } // setters and getters }
在上述的例子中,可以发现,在Annotation中所指定的内容是一个URL Template,如果你有一个url,可以匹配上面的URL Template,那么url将匹配到这个Action的method,并且将对应位置的值注入到Action中的同名参数中。
不仅如此,LightURL还能够支持AntPath的URL匹配。这样可以通过书写/blogs/common/*或者/blogs/**来匹配多个不同的URL映射。
针对上面的例子:
http://host:port/app/blogs/2008/08/07将被映射到这个Action的execute,并且2008,08和07分别映射到year,month和day中。
http://host:port/app/blog/2345/edit将被映射到Action的edit方法,并且2345映射到id中作为参数
http://host:port/app/blogs/common/abcd将被映射到Action的common方法。
URL的匹配顺序与重复配置的校验
在上面的例子中,介绍了那么多的url映射到Action中的方式。他们之间可能会出现冲突,有些冲突,LightURL会在系统启动时为你检查出来,并强制要求你纠正它,而有些冲突,则通过优先级匹配的方式进行。
下列冲突将被认为是你必须在系统启动前就进行纠正的:
1. Annotation中定义的URL Template互相之间冲突
例如:/blogs/${year}/${month}/${day}和/blogs/${category}/${id}/edit就是冲突的。
2. Annotation中定义的URL Template与其他Annotation中定义的完全匹配URL冲突
例如:/blogs/${year}/${month}和/blogs/category/index就是冲突的。
3. Annotation中定义的URL Template与形如/entity/${id}的url定义冲突
例如:/user/${id}形式的Annotation定义可能会与系统默认支持的冲突。
在其他情况下,如果你定义的URL映射互相直接有冲突,那么LightURL将根据某个顺序进行URL匹配,并找到第一个匹配的映射方式,然后放弃查找。这个顺序为:
1. 首先进行Namespace匹配,如果url恰好能匹配某个namespace,并且其对应的package下有Index作为Action,那么直接进行匹配。
2. 其次查看所有的Annotation定义中,是否存在完整的URL匹配,如果找到,那么进行直接匹配。
3. 接着进行package匹配,将url分解成相应的namespace和actionName,与已有的配置进行匹配,如果找到,那么直接匹配。
4. 然后进行entity匹配,看看url是否形如:/entity/${id},如果是,那么直接匹配。
5. 最后进行Annotation定义的Url Template匹配。
如果所有的五种情况都无法进行匹配,那么这个URL将无法被LightURL识别,继续交由Struts2进行后续处理。
上面所描述的内容都是Url到Action的映射。下面的部分,描述的是如何在Action执行完毕之后,转到相应的结果view。
Codebehind
LightURL支持codebehind。有关codebehind的相关知识,可以参考struts2的相关文档:
http://struts.apache.org/2.x/docs/codebehind-plugin.html
有了codebehind的支持,那么从Action转到类似jsp,ftl或者vm的view层组件就不需要任何配置,只要符合一定的命名规范,就可以直接进行转向。
在这里,LightURL不仅实现了Codebehind的所有功能。而且,LightURL还对Codebehind的规则做出了扩展。
Codebehind在寻址JSP等资源时,顺序按照以下的规则进行:
1. /namespace/actionName-<resultCode>.<ext>
2. /namespace/actionName.<ext>
而LightURL在寻址JSP等资源时,增加了一定的规则,并且按照如下顺序进行:
1. /namespace/actionName-<resultCode>.<ext>
2. /namespace/<resultCode>.<ext>
3. /namespace/actionName.<ext>
4. /namespace/namespace-actionName-<resultCode>.<ext>
5. /namespace/namespace-<resultCode>.<ext>
6. /namespace/namespace-actionName.<ext>
这样一来,大家就有更加宽广的选择范围,进行默认资源的寻址匹配了。
ResultCode的识别
但是在很多情况下,我们需要的是全方位的Result类型的支持。例如,有的时候我们需要返回JSON Result,有的时候,我们可能需要Redirect到一个新的Action。此时,我们不得不为此增加一些配置,或者借助Annotation来完成。
为此,LightURL提供了一种根据ResultCode进行识别的命名方式来匹配你所指定的Result。
以JSON Result为例,你可以这么写:
package com.demo2do.lighturl.action.user; import com.demo2do.lighturl.entity.User; import com.opensymphony.xwork2.ActionSupport; /** * @author Downpour * */ public class Index extends ActionSupport { private static final long serialVersionUID = -5017825114664788765L; private User user; /* (non-Javadoc) * @see com.opensymphony.xwork2.ActionSupport#execute() */ @Override public String execute() throws Exception { return "j:user"; } // setters and getters }
在这里,你可以发现,resultCode变成了j:user。那么此时,LightURL会将这个resultCode识别成:请返回JSON Result,并且JSON的Result的root为user对象。
再例如:
package com.demo2do.lighturl.action.user; import com.demo2do.lighturl.entity.User; import com.opensymphony.xwork2.ActionSupport; /** * @author Downpour * */ public class Index extends ActionSupport { private static final long serialVersionUID = -5017825114664788765L; private User user; /* (non-Javadoc) * @see com.opensymphony.xwork2.ActionSupport#execute() */ @Override public String execute() throws Exception { return "r:/user/add-user"; } // setters and getters }
在这里,"r:/user/add-user"会被识别成:请返回Redirect Result。Redirect的URL为/user/add-user。
LightURL默认情况下,实现了对Redirect Result和JSON Result的ResultCode识别,并将他们的前缀分别定制为:"r:"("redirect:")或者"j:"("json:")。
当然,你可以根据你自己的情况,实现你自己的ResultCode的识别程序,你只需要实现com.demo2do.lighturl.result.ResultCodeConfig接口即可。并在struts.properties中指定你希望LightURL进行ResultCode匹配的顺序。
lighturl.result.code.config=yourpackage.ResultCodeConfigImpl1,yourpackage.ResultCodeConfigImpl2
这样,LightURL会根据你所指定的顺序,依次进行ResultCode的匹配,直到找到第一个匹配的Result Type为之。
当然,默认情况下,LightURL的匹配顺序为:
codebehind -> 你自定义的ResultCode识别实现 -> json -> redirect
- struts2-lighturl-plugin-source-0.9.jar (40.5 KB)
- 下载次数: 409
- struts2-lighturl-plugin-0.9.jar (58.9 KB)
- 下载次数: 364
评论
36 楼
lolo6062
2008-12-11
怎么和codebehind结合啊,引入2个jar包后报错,错误原因是struts-plugin.xml中的
<bean type="com.opensymphony.xwork2.UnknownHandler" class="org.apache.struts2.codebehind.CodebehindUnknownHandler" />
和你的那个重复了,
com.opensymphony.xwork2.UnknownHandler class:com.demo2do.lighturl.LightURLUn
请问如何解决啊,我是初学者,问的比较肤浅,谢谢
<bean type="com.opensymphony.xwork2.UnknownHandler" class="org.apache.struts2.codebehind.CodebehindUnknownHandler" />
和你的那个重复了,
com.opensymphony.xwork2.UnknownHandler class:com.demo2do.lighturl.LightURLUn
请问如何解决啊,我是初学者,问的比较肤浅,谢谢
35 楼
downpour
2008-12-03
gmogu 写道
请问楼主如何配置返回页面?
有无数人问我这个问题。难道大家都不仔细阅读我的说明嘛?
downpour 写道
LightURL支持codebehind。有关codebehind的相关知识,可以参考struts2的相关文档:
http://struts.apache.org/2.x/docs/codebehind-plugin.html
有了codebehind的支持,那么从Action转到类似jsp,ftl或者vm的view层组件就不需要任何配置,只要符合一定的命名规范,就可以直接进行转向。
就算不仔细阅读我的说明,struts2的文档总该看一下吧。
34 楼
gmogu
2008-12-03
请问楼主如何配置返回页面?
33 楼
qiaoxia_lan
2008-11-20
好的。呵呵
32 楼
downpour
2008-11-18
更新了附件,加强了日志调试输出,并修复了一些潜在的bug。
31 楼
linux.sir
2008-11-04
想知道lighturl能否结合commontemplate模板来使用?
30 楼
pxpaul
2008-10-28
这里的例子和apache网站上的还有点不一样的地方,比如说web.xml的配置,为什么会不一样呢?
学习中……
学习中……
29 楼
speedy
2008-10-18
个人认为像这样的东西有一个不好,注释多了,对维护的时候会有一点不知所措,也就是说很难找到你的源代码,除非代码规划得非常好。相反,都写在xml文件中的话,会相对容易一点
28 楼
lgstarzkhl
2008-10-15
这个结合spring之后还可以用吗?
27 楼
eeeeeeee
2008-10-13
等了一天,估计楼主是不会回来了
26 楼
QuakeWang
2008-10-13
downpour 写道
前几天有一个朋友向我指出LightURL的一个问题,这也可能是很多CoC存在的问题。在使用xml配置的年代,需要根据URL来找一个Action相对比较方便,因为只要在一个文件中进行查找就好了。但是使用CoC之后,并没有一个具体的文件来记录这些对应关系,所以想查找这样的对应关系非常的困难。
开发环境中配置一个debug拦截器,在每个请求的时候console输出被调用的action以及其他调试信息(request parameter等),方便进行查找
配合Eclipse或者NetBeans等IDE打开文件特性,可以直接点击console输出打开对应的文件。
25 楼
375721064
2008-10-13
org.apache.commons.lang.StringUtils这里总报错 是导的哪个包
24 楼
eeeeeeee
2008-10-12
对应的页面是怎么配置的?struts2是在xml里面将action对应的的<result>/{test}</result>
大侠说的这种方法怎么对应页面呢?
大侠说的这种方法怎么对应页面呢?
23 楼
caiceclb
2008-10-12
什么时候能够这样:
比如访问:/url/server.html或访问/url/server......这样的url
很自然就定位到唯一的文件,就像访问主页一样,总是index文件
这个想法还不成熟,我暂时称为自然访问服务。
比如访问:/url/server.html或访问/url/server......这样的url
很自然就定位到唯一的文件,就像访问主页一样,总是index文件
这个想法还不成熟,我暂时称为自然访问服务。
22 楼
linux.sir
2008-10-06
不知道怎么返回freemarker类型?
21 楼
yidwo
2008-10-02
当项目大时,从URL查找对应的类就麻烦了.
20 楼
leisure
2008-09-30
看上去不错,不过配置文件散开了,反而不好管理了
所以个人觉得还是把配置文件放在一起好。
所以个人觉得还是把配置文件放在一起好。
19 楼
robbin
2008-09-29
downpour 写道
tywo45 写道
struts2.1.2已经有这个功能了
struts2.1.2只是增加了annotation功能,但是不支持类似url template和某些特殊的url映射。
前几天有一个朋友向我指出LightURL的一个问题,这也可能是很多CoC存在的问题。在使用xml配置的年代,需要根据URL来找一个Action相对比较方便,因为只要在一个文件中进行查找就好了。但是使用CoC之后,并没有一个具体的文件来记录这些对应关系,所以想查找这样的对应关系非常的困难。
Rails的routes.rb就是描述URL映射的,rails也带了rake,一个命令就可以打印出来整个web应用的所有URL对应关系,所以查找不是问题。
18 楼
downpour
2008-09-29
tywo45 写道
struts2.1.2已经有这个功能了
struts2.1.2只是增加了annotation功能,但是不支持类似url template和某些特殊的url映射。
前几天有一个朋友向我指出LightURL的一个问题,这也可能是很多CoC存在的问题。在使用xml配置的年代,需要根据URL来找一个Action相对比较方便,因为只要在一个文件中进行查找就好了。但是使用CoC之后,并没有一个具体的文件来记录这些对应关系,所以想查找这样的对应关系非常的困难。
17 楼
tywo45
2008-09-28
struts2.1.2已经有这个功能了
发表评论
-
Struts2的一些不尽人意的地方,兼答hantsy
2012-01-06 10:21 4805hantsy 写道 在 Webwork 合并到Apache S ... -
《Struts2技术内幕》 新书部分篇章连载(七)—— ThreadLocal模式
2012-01-05 14:39 14859第4章 源头活水 —— Str ... -
《Struts2技术内幕》 新书部分篇章连载(六)—— 框架的本质
2012-01-05 14:02 4890第2章 固本清源 —— Web ... -
《Struts2技术内幕》自评 —— 尚未完成的话题
2011-12-30 11:11 4256此文接我另外一篇博客:新书上市:《Struts2技术内幕》 ... -
新书上市:《Struts2技术内幕》
2011-12-26 14:28 10614我的新书《Struts2技术内 ... -
《Struts2技术内幕》 新书部分篇章连载(四)—— 核心分发器
2011-10-27 20:15 75699.2核心分发器 —— Dispa ... -
《Struts2技术内幕》 新书部分篇章连载(五)—— 请求响应哲学
2011-10-27 20:01 14107第7章 别具匠心 —— XWork设计原理 众所周知,现代电 ... -
《Struts2技术内幕》 新书部分篇章连载(三)—— 多视角透析Struts2
2011-10-27 19:09 88663.3 多视角透析Struts2 Str ... -
《Struts2技术内幕》 新书部分篇章连载(一)—— 如何学习开源框架
2011-10-27 18:40 162432.6 如何学习开源框架 ... -
《Struts2技术内幕》 新书部分篇章连载(二)—— 面向对象浅谈
2011-10-26 19:46 9771第2章 固本清源 —— Web ... -
《Struts2技术内幕》 新书样章和导读
2011-10-27 20:40 5108由于本书尚未出版,我 ... -
介绍一个PDF的生成方案
2009-11-03 17:15 37611在Java世界,要想生成PDF ... -
Spring Security 2 配置精讲
2009-01-22 15:19 29486论坛上看了不少Spring Sec ... -
若干条J2EE应用中运用“配置”的最佳实践
2008-04-22 17:07 3748本文所提到的所有内容 ... -
OpenSessionInView详解
2006-11-01 17:13 17341OpenSessionInViewFilter是Sprin ... -
一个简单的ServletContextLoader装载器
2006-09-26 10:49 7010在很多项目中,会碰到一种需求,就是在应用服务器启动的时候,把一 ... -
Struts与Spring整合的几种方法
2006-09-12 15:00 23594论坛中用Struts+Spring的人不少,以前的帖子也有问过 ...
相关推荐
总之,《Struts2技术内幕——深入解析Struts2架构设计与实现原理》配合《struts2基础.chm》,将帮助读者全面掌握Struts2的架构设计、核心组件、配置方式、插件使用以及源码解读,对于想要在Java Web领域深入发展的...
要深入学习和掌握Struts2,建议阅读官方文档,参与实际项目实践,也可以参考相关的技术书籍和教程,例如《Struts2技术内幕——深入解析Struts2架构设计与实现原理》等资源,来提升对Struts2框架的全面理解。
Struts2通过约定优于配置的方式,可以根据Action类名自动映射URL。 9. **创建视图页面**:编写JSP页面作为视图,使用Struts2的标签库(struts2-jsp-plugin)来展示数据和处理用户交互。 10. **部署和测试**:将...
然后厘清了Web开发中极易混淆的一些重要概念,以及Struts2的核心技术、宏观视图、微观元素、配置元素等,提纲挈领地对Struts2进行了多角度的讲解。核心技术篇首先分析了Struts2中多种具有代表性的设计模式,然后对...
总的来说,"Struts2 技术内幕——深入解析Struts2架构设计"这本书将带你深入理解Struts2的工作原理,包括其架构设计、核心组件、配置方式、数据绑定、异常处理以及安全性等方面。通过对这些知识点的掌握,开发者能够...
Struts2零配置是Struts2框架的一种简化配置方式,旨在减少XML配置文件的使用,提高开发效率。在传统的Struts2应用中,开发者需要在多个XML文件中配置Action、结果页面、拦截器等,而“零配置”则是对这种繁琐配置的...
6.Struts2中的零配置与CoC(Convention over Configration).doc 7.Struts2介绍之使用链接标签.doc 8.Struts2入门.doc 9.Struts2学习进阶(基础篇1-7) 10.Struts2学习进阶(实例篇1)——struts2-blank-2.0.8实例...
《项目架构那点儿事》——浅析Web层Struts2的构建 在Web开发领域,Struts2作为一款流行的MVC框架,为开发者提供了高效、灵活的架构支持。本篇文章将深入探讨Struts2在Web层的构建过程,通过分析提供的文件名,我们...
2. 创建和配置Struts2应用,包括Action、Result和Interceptor的使用 3. Hibernate的配置,实体类和映射文件的编写,以及数据操作方法 4. HQL和Criteria API的使用,以及Hibernate的缓存机制 5. Spring框架的核心概念...
本文将详细介绍Struts2中的两个插件——Zero Config(零配置)与CodeBehind,以及它们如何共同工作以减少配置文件的复杂度。 #### 二、Zero Config插件介绍 Zero Config插件的主要目的是减少甚至消除`struts.xml`...
在Java Web开发中,Struts2是一个非常流行的MVC(模型-视图-控制器)框架,它提供了一种结构化的方式来组织应用程序,提高了开发效率。Eclipse作为Java开发的主要IDE,配置Struts2可以让开发者在其中便捷地进行...
总的来说,STRUTS2 Convention零配置大大减少了XML配置文件的需求,提高了开发效率。通过合理的包结构和类命名,开发者可以快速构建出符合MVC模式的应用,同时享受到自动化的便利。然而,需要注意的是,过度依赖约定...
书中通过大量的示范性实例(全书范例近百个),逐一、详细地讲解了Struts2各知识点的用法,并细致地讲解每个用法的各种参数、选项,可以帮助读者入门到精通。 3.配合案例,快速提高 《Struts 2.1权威指南》最后配备...
综上所述,Struts2的零配置特性大大简化了Java Web应用的开发,通过注解和插件机制,开发者可以快速构建应用而无需过多关注XML配置。不过,理解如何恰当地使用这些工具以及它们对性能的影响仍然是至关重要的。在实际...
首先,Struts2的出现是为了解决Struts1在MVC模式中的局限性,它通过提供更灵活的配置、更强大的拦截器(Interceptor)体系以及与Spring等其他框架的无缝集成,提升了开发效率和应用性能。框架的核心组件包括Action、...
**Struts2** 是一款开源的Java Web应用框架,用于简化Web应用程序的开发过程。它基于MVC(Model-View-Controller)设计模式,提供了一套标准的方式来构建应用程序。相比于Struts1,Struts2在架构上更加灵活,并且支持...