在以前,如果别人让我帮他做个网站之类的,我一般不乐意。为什么?工作量大,就比如写个servlet,无论你用javax.servlet.HttpServlet还是用structs等框架来编写,都不轻松。
用servlet吧,参数解析,繁重的编码量会搞得自己很郁闷。那好,用struts,用了struts以后好多了,参数直接给你映射到javabean里了,而且你也可以直接指定调用actionProcessor的某个方法。但是接下来的那一堆配置呢?配错了一点,跑不起来了吧。进一步说,你要想完全发挥struts的威力,你不对他进行1两的年的学习,我只能说很难。配置、api都够学上一段时间。而且当你还想再灵活的时候,恐怕就要和struts的源代码做亲密接触了。
针对小型的应用,我用了另外一种方法,“不采用配置,而根据习惯”。也就是说大部分编程人员都这样做的,我就不再做规定,而直接使用。
大的模型依然是mvc,视图用jsp+jstl,controller用action,model依然是javabean。但是怎样把视图和控制器联系起来呢?这个联系是双向的从视图到controller,然后从controller再到视图。第二个方向不用说了,大家都知道。
第一个方向呢,我模仿struts的做法。但是最大的不同是,我简化了配置:我用一句话来配置所有的action,我指定所有ActionProcessor所在的包名(前提是把他们放到一个包里)。当一个http://localhost:8080/app/ActionCategory!delete.action这样的链接把请求发到服务器时,我就能取到类名ActionCategory和方法名delete,然后利用反射调用delete方法。这样整个过程就完成了。
看一个表单的例子:
再看下action的典型写法:
再看下所有的配置,仅仅配了一个filter,初始化参数是actionProcessor所在的包名:
这样,我使用一种相对简单的办法就完成了这个以前要写很多代码和配置,或者大量if else语句才能搞定的东西。而且整个东西是可以复用的,不依赖于任何应用。
到此为止,这个以前最让我烦的东西就搞定了。虽然说现在的ide可以帮我们做配置这类的工作,不可否认,修改和维护所花费的时间是不少的。我这里是使用了约定和自己的coding习惯,直接当作规则来使用,不再另加约束。所以省掉了。
在这一环节中,相对来说比较繁琐和重复的工作就是参数的解析,我做了一个工具ServletUtil,其中一个方法就是直接把参数给解析成javabean。这个纯粹是工作量的东西也省掉了。
mvc中重要的一个环节就是模型了,模型部分我也做了封装,尽量避免配置,而使用习惯。争取更大限度的去除重复的编码。下次有机会再写。
用servlet吧,参数解析,繁重的编码量会搞得自己很郁闷。那好,用struts,用了struts以后好多了,参数直接给你映射到javabean里了,而且你也可以直接指定调用actionProcessor的某个方法。但是接下来的那一堆配置呢?配错了一点,跑不起来了吧。进一步说,你要想完全发挥struts的威力,你不对他进行1两的年的学习,我只能说很难。配置、api都够学上一段时间。而且当你还想再灵活的时候,恐怕就要和struts的源代码做亲密接触了。
针对小型的应用,我用了另外一种方法,“不采用配置,而根据习惯”。也就是说大部分编程人员都这样做的,我就不再做规定,而直接使用。
大的模型依然是mvc,视图用jsp+jstl,controller用action,model依然是javabean。但是怎样把视图和控制器联系起来呢?这个联系是双向的从视图到controller,然后从controller再到视图。第二个方向不用说了,大家都知道。
第一个方向呢,我模仿struts的做法。但是最大的不同是,我简化了配置:我用一句话来配置所有的action,我指定所有ActionProcessor所在的包名(前提是把他们放到一个包里)。当一个http://localhost:8080/app/ActionCategory!delete.action这样的链接把请求发到服务器时,我就能取到类名ActionCategory和方法名delete,然后利用反射调用delete方法。这样整个过程就完成了。
看一个表单的例子:
<
form
method
="post"
action ="${requestScope.contextPath}/ActionCategory!delete.action"
name ="delete" >
< input type ="hidden" value ="${cata.id}" name ="id" >
< input type ="submit" value =" 删除 " name ="submit" >
</ form >
action ="${requestScope.contextPath}/ActionCategory!delete.action"
name ="delete" >
< input type ="hidden" value ="${cata.id}" name ="id" >
< input type ="submit" value =" 删除 " name ="submit" >
</ form >
public
void
delete(HttpServletRequest request, HttpServletResponse response)
throws ServletException, SQLException, IOException {
Product product = (Product) ServletUtil.requestParam2Bean(request,
Product.class, new String[] { "id", "categoryId" });
ProductDao.delete(product.getId());
listByCategoryId(request, response, product.getCategoryId());
}
throws ServletException, SQLException, IOException {
Product product = (Product) ServletUtil.requestParam2Bean(request,
Product.class, new String[] { "id", "categoryId" });
ProductDao.delete(product.getId());
listByCategoryId(request, response, product.getCategoryId());
}
<
filter
>
< filter-name > autumnSunshineApp </ filter-name >
< filter-class > com.zhmt.webapp.FilterAutumnSunshine </ filter-class >
< init-param >
< param-name > actionProcessorPackage </ param-name >
< param-value > com.zhmt.bjmq.action </ param-value >
</ init-param >
</ filter >
< filter-mapping >
< filter-name > autumnSunshineApp </ filter-name >
< url-pattern > *.action </ url-pattern >
</ filter-mapping >
< filter-name > autumnSunshineApp </ filter-name >
< filter-class > com.zhmt.webapp.FilterAutumnSunshine </ filter-class >
< init-param >
< param-name > actionProcessorPackage </ param-name >
< param-value > com.zhmt.bjmq.action </ param-value >
</ init-param >
</ filter >
< filter-mapping >
< filter-name > autumnSunshineApp </ filter-name >
< url-pattern > *.action </ url-pattern >
</ filter-mapping >
到此为止,这个以前最让我烦的东西就搞定了。虽然说现在的ide可以帮我们做配置这类的工作,不可否认,修改和维护所花费的时间是不少的。我这里是使用了约定和自己的coding习惯,直接当作规则来使用,不再另加约束。所以省掉了。
在这一环节中,相对来说比较繁琐和重复的工作就是参数的解析,我做了一个工具ServletUtil,其中一个方法就是直接把参数给解析成javabean。这个纯粹是工作量的东西也省掉了。
mvc中重要的一个环节就是模型了,模型部分我也做了封装,尽量避免配置,而使用习惯。争取更大限度的去除重复的编码。下次有机会再写。