RequestMapping(@RequestMapping) with Spring, or How Strange Is That?

@RequestMapping

 

1、 @RequestMapping 被处理的条件：
       在dispatcher中出现对应的 HandlerMapping（为了实现类型级别的注解）和HandlerAdapter（为了实现方法级别的注解）这在DispatcherServlet和DispatcherPortlet中都是默认的.

2、@RequestMapping 注解的方法可以拥有下面类型的方法（顺序任意，除非对于验证结果需要紧跟在对应的命令对像后面）

   1）. 请求/响应对像（Servlet api or Portlet api）

   2）. 会话对像（Servlet API or Portlet API）

   3）. WebRequest/NativeWebRequest

   4）. InputStream/Reader 用于访问请求的内容

   5）. OutputStream/Writer 用于生成响应的内容

   6）. 以 @RequestParam 注解的参数用于访问特定的 Servlet/Portlet 请求参数。参数值将被转换为声明的方法参数类型

   7）. Map/Model/ModelMap 用于充实将被暴露到 Web 视图的隐含模型

   8）. 绑定参数到命令/表单对像：带有自定义类型转换的 bean 属性/域， 依赖于 @InitBinder 方法/HandlerAdapter 配置，参见AnnotationMethodHandlerAdapter 的 "webBindingInitializer" 属性，这样的命令对像包括它们的验证结果，将会暴露为模型属性，默认的会在属性注解中使用非限定的命令类名（如：对于类型 "mypackage.OrderAddress" 使用 "orderAddress" ）。为声明一个体特定的模型属性名称指定一个参数级别的 ModelAttribute 注解

   9）. BindingResult 验证结果用于前面的一个命令/表单对像（前面紧接的参数）

   10）. SessionStatus 状态处理用于把表单处理过程标记为已完成（触发会话属性的清理，这些会话属性是在句柄类型级别由 @SessionAttribute 注解指示出的）

 3 、@RequestParam 注解的参数默认是必须的，设置 @RequestParam（value="id",required="false"）则这个参数为可选的

Spring portlet Demo

http://www.cnblogs.com/rubys/archive/2009/04/22/1441671.html

Spring JSR-250注解 

http://www.cnblogs.com/rubys/archive/2009/02/04/1384139.html

RequestMapping with Spring, or How Strange Is That?

October 8th, 2009 geoff Leave a comment Go to comments

My new job has given me a chance to get into learning Spring in depth. I’ve dabbled with Spring before but never used it in anger, so I’ve been enjoying this opportunity. While doing this I’ve been intrigued by a technique of theirs that’s so unfamiliar to me it seems almost like a new way of programming altogether. I came across it in the context of Spring MVC, but it’s a general purpose technique that could be used anywhere.

So say you want to write some code that works with an existing framework or library. What I’ve been used to, in C++ or Java, is the traditional OO approach of implementing an interface provided by the library, or perhaps subclassing a concrete class, and then handing the object you’ve constructed to the library/framework to do its work. For example to write a Java servlet you might well create a class that implements the doGet interface:

protected void doGet(HttpServletRequest req,    HttpServletResponse resp) throws ServletException, IOException;

This is a typical OO situation; what is happening here is that the container interacts with you through the interface it understands, you then extract the data you want from the request objects, e.g. with request.getParameter(), crunch it whatever way you need, and maybe hand the result back through another interface. Your method that implements the interface is like a “mapping” layer in the code, sitting between the framework and your business logic and gluing them together.

Spring supports this approach too, of course. For example, you might implement an MVC controller by subclassing AbstractController and then providing your own implementation of

 public ModelAndView handleRequestInternal(    HttpServletRequest request,     HttpServletResponse response) throws Exception;

But there’s another way to do things. Spring provides annotations that you can place on your classes and methods that provide amazing flexibility about how you access data from the framework. To some extent it eliminates that “mapping” layer of the interface implementation. To get at the data in a request, instead of implementing a particular interface like handleRequestInternal above, you can write a method annotated with @RequestMapping:

@RequestMapping(method = RequestMethod.GET)    public String myMethod( ... );

OK, so this gives you a method that will get the details from a GET request, but what signature should it have? Er, … well, pretty much anything you like. As explained in the Spring documentation, “Handler methods which are annotated with @RequestMapping are allowed to have very flexible signatures.”

Too right. When you add the @RequestMapping annotation to your method, Spring will analyse its parameter and return types, and provide the appropriate values when the method is called. For example you can add in parameters to your method for the request or response objects; for the session object; or raw input or output streams. If you’re working in an internationalized setup you can just pop in the Locale. If you have several request parameters you can specify which one goes where with the @RequestParam annotation on the method parameter in question. You can have a “command” object that has multiple properties, and Spring will match up the request parameter with the properties of the same name. You can even write a Spring “Binder” object to convert from a string request parameter into an arbitrary type of your own devising.

Say for example you have a dropdown list called “mySelection”, and a number of text boxes (”name”, “address1″, “postcode” …) to gather address details from the user. You might have a controller with a method to get this information that looks like

@RequestMapping("/address.do")public String getAddressFromUser(    @RequestParam("mySelection") String mySelection,    AddressDetails addressDetails,    ModelMap model) {    ...}

Here @RequestParam gives you the value selected in the dropdown, and AddressDetails is a “command” object, whose properties get set from the address related request parameters, whose names are the same as the properties of AddressDetails. This command object also is handily stored in the model object by Spring, so you don’t have to arrange for that yourself. But you could do things quite differently. Here’s another option

@RequestMapping("/address.do")public String getUserAddress(    ServletRequest request,    ModelMap model,    MyFormFields myFields,    BindingResult result) {    ...    doSomethingWith(myFields.getMySelection());    ...}

Here we have decided to get at the servlet request itself, and to map all of the incoming parameters into the MyFormFields command object, rather than treat them in two parameters as before. Also there’s a BindingResult which tells you whether all the properties in the MyFormFields were set (bound) from the request, or which ones weren’t. And you noticed, of course, that the two methods aren’t even named the same. There are similar flexible possibilities for the return value, and various other ways you can specify the mapping itself in @RequestMapping, but this is getting long enough already.

How weird is all that? It’s certainly a very different approach to the traditional interface/implementation based one. Imagine if we all started writing software like this. When I first came across this technique I was unsure what I thought about it, and was worried that it would just make the code harder to understand. But all it takes is a bit of getting used to, and having worked with it for a while now I’m beginning to like it. In practice it makes life easier, which is what Spring is all about. Wonder what other goodies they have in store? Can’t wait to find out.

http://www.geoffmacartney.com/blog/?p=57