<!-- BeanNameUrlHandlerMapping -->
<bean id="beanNameUrlHandlerMapping" class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping">
<property name="alwaysUseFullPath" value="true"></property>
<property name="order" value="1"></property>
</bean>
<!--
※ 『BeanNameUrlHandlerMapping』
HTTP 요청 URL과 빈(bean)의 이름을 비교하여
일치하는 빈(bean)을 찾아주는 역할을 수행한다.
빈 이름에는 『*』, 『**』, 『?』를 이용한 패턴을 넣을 수 있다.
(ANT 패턴)
하지만, 컨트롤러의 갯수가 많아지면
URL 정보다 XML 이나 Annotation에 분산되어 파악이 어렵기 때문에
복잡한 애플리케이션에서는 사용하지 않는 것이 바람직하다.
ex)
<bean name="/hello*" class="HelloController" />
→hello 로 시작하면 모두 여기에 매핑된다.
<bean name="/root/**/sub" class="SubController" />
→ 『**』는 하나 이상의 경로를 매핑할 수 있다.
- alwaysUseFullPath
: URL 매핑은 기본적으로
『어플리케이션 컨텍스트 패스』 , 『서블릿 패스』 를 제외한
나머지만 가지고 비교하게 된다.
즉, 어플리케이션이 『/test』에 배포되고,
DispatcherServlet URL mapping 이 『/app/*』일 경우
전체 URL은 『/test/app/hello』 와 같은 형태가 되지만
핸들러 매핑은 『/hello』만을 대상으로 삼는다는 의미이다.
이는 애플리케이션이나 서블릿이 변경되어도
애플리케이션의 매핑 구조는 영향을 받지 않게 하기 위해서이다.
『 alwaysUseFullPath』 옵션을 true로 설정하면
이를 해제하고 모든 URL을 대상으로 변경할 수 있다.
- order
: 핸들러 매핑은 한 개 이상을 동시에 사용할 수 있다.
한 개의 매핑으로 사용하는 것이 이상적이지만
그렇지 않은 상황이 존재한다.
두 개 이상의 핸들러 매핑이 등록되었는데
두 개 이상의 핸들러 매핑이 등록된 상황에서
URL이 중복 매핑될 경우,
『order』 프로퍼티를 통해 매핑 우선순위를 지정할 수 있다.
『order』 프로퍼티의 값이 작은 매핑 전략이 높은 우선순위를 갖는다.
-->
<!-- 태민이 설명
HandlerMapping
-MVC패턴의 핵심은 『컨트롤러』를 통해 진입한다는 것.
-HandlerMapping 하면 servlet / servlet-mapping이 떠올라야함
-컨트롤러로 진입한다는 것은 요청이 들어왔다는것, 그것에 맞는 응답이 있어야한다는것
-단일 요청에 단일 응대라면... 하나의 어플리케이션이 받는 요청이 1000개라면...
매핑구조를 1000개를 만들어야함
-1000개의 요청에을 1000개의 매핑을 해줄수는 없기에....
패턴을 나눠서 분류(유형에 따라 분류) → 핸들러매핑(5가지의 유형)
[요청의 유형에 따라 분류하는것.]
- 그중에 우리가 배울 것 BeanNameUrlHandlerMapping
ViewResolver : 비서 (컨트롤러 따까리)
컨트롤러는 얄미운놈.
(벽돌날라주세요 라는 요청이 들어오면 자신이 하지 않고, 시킴.)
(벽돌날라주는것 을 시키는것 조차도 대상을 명확히 파악하는것이 아니라,
~잘하는 팀 이런식으로 시키는 구조
: 비서야! 알아보고 잘하는애한테 시켜!)
디폴트 ViewResolver가 있는데 커스터마이징 해서 등록해주게 되면 간편하게 쓸수있음
//mav.setViewName("/WEB-INF/view/EmployeeList.jsp");
→
// mav.setViewName("EmployeeList.jsp");
-->
단 .action 과 같이 url-pattern을 지정한것을 호출하려면
mav.setViewName("redirect:employeelist.action");
와 같이 redirect:를 써야한다.
여기서 redirect는 스프링 컨테이너에게 클라이언트가 이 링크를 다시 요청하도록 처리해달라고 하는것으로
스프링 컨테이너에게 보내는 메세지이다.
<!-- InternalResourceViewResolver -->
<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<!-- "WEB-INF/view/EmployeeList.jsp" -->
<!-- "/WEB-INF/view/" + "EmployeeList" + ".jsp" -->
<property name="prefix" value="/WEB-INF/view/"></property>
<property name="suffix" value=".jsp"></property>
</bean>
<!--
※ 『InternalResourceViewResolver』
스프링 컨트롤러는 뷰에 의존적이지 않다.
컨트롤러가 지정한 뷰 이름으로부터
응답 결과 화면을 생성하는 뷰 객체는 ViewResolver가 얻어낸다.
스프링은 몇 가지 ViewResolver 구현 클래스를 제공하고 있는데,
이 중 주요 ViewResolver 구현 클래스는 다음과 같다.
- InternalResourceViewResolver
: 뷰 이름으로부터 JSP 나 타일즈(Tiles) 연동을 위한
View 객체를 반환한다.
- VelocityViewResolver
: 뷰 이름으로부터 Velocity 연동을 위한 View 객체를 반환한다.
- VelocityLayoutViewResolver
: VelocityViewResolver의 하위 객체로
VelocityViewResolver와 동일한 기능을 제공하며
이에 더하여 Velocity 의 레이아웃 기능을 제공한다.
- BeanNameViewResolver
: 뷰 이름과 같은 이름을 갖는 빈 객체를 View 객체로 사용한다.
- ResourceBundleViewResolver
: 뷰 이름과 View 객체 간 매핑 정보를 저장하기 위해
Resource 파일을 사용한다.
- XmlViewResolver
: 뷰 이름과 View 객체 간 매핑 정보를 저장하기 위해
XML 파일을 사용한다.
※ ViewResolver Interface
- ViewResolver 는 뷰 이름과 지역화를 위한
Locale 을 파라미터로 전달받으며,
매핑되는 View 객체를 반환한다.
매핑되는 View 객체가 존재하지 않으면 null을 반환한다.
※ View 객체
- 『getContentType()』 메소드는 "text/html"』과 같은
응답 결과의 컨텐츠 타입을 반환한다.
『render()』 메소드는 실제로 응답 결과를 생성한다.
『render()』 메소드의 첫 번째 파라미터인 model 에는
컨트롤러가 반환한 ModelAndView 객체의 모델 데이터가 전달된다.
각각의 View 객체는 이 모델 데이터로부터 응답 결과를 생성하는데
필요한 정보를 얻어낸다.
※ InternalResourceViewResolver 설정
- InternalResourceViewResolver 클래스는 JSP나 HTML 파일과 같이
웹 어플리케이션의 내부 Resource를 이용하여 뷰를 생성하는
AbstractUrlBasedView 타입의 뷰 객체를 반환한다.
기본적으로 사용하는 뷰 클래스는 InternalResourceView 클래스이다.
- InternalResourceViewResolver는
컨트롤ㄹ러가 지정한 뷰 이름으로부터 실제로 사용될 뷰를 선택하는데,
이 때, 컨트롤러가 지정한 뷰 이름 앞뒤로
prefix 프로퍼티와 suffix 프로퍼티를 추가한 값이
실제로 사용될 Resource의 경로가 된다.
-->