(스프링) 6장 웹 뷰 렌더링
1. 뷰 리졸루션 이해하기
컨트롤러의 요청-처리 로직과 뷰의 뷰-렌더링의 분리는 스프링 MVC의 중요한 기능이다.
컨트롤러 메소드가 직접적으로 HTML을 생성하게 된다면, 요청-처리 로직에 손을 대지 않고서는 뷰의 관리나 업데이트가 매우 어려울 거시다. 대부분 컨트롤러 메소드와 뷰의 구현은 모델의 내용에는 동일함이 있어야 한다. 하지만 컨트롤러가 단지 논리적인 이름으로만 뷰를 알 수 있다면, 스프링이 모델을 실제로 렌더링하기 위해 구현되어 있는 뷰를 어떻게 결정할까?
이것이 스프링의 뷰 리졸버의 역할이다.
InternalResourceViewResolver를 사용한다. 이 리졸버는 모델을 렌더링하게 될 뷰의 물리적인 위치로 전달되는 논리적 뷰 이름에 접두사(prefix)로 /WEB-INF/views/를 붙이고 접미사로(suffix)로 .jsp를 붙이도록 되어 있다.
스프링MVC는 다음과 같은 ViewResolver 인터페이스를 정의한다.
ResolveViewName()메소드는 뷰의 이름과 Locale를 넘겨 받고 View 인스턴스를 리턴해준다.
View인터페이스는 다음과 같다.
뷰 인터페이스 역할은 모델을 전달받는 것 뿐만아니라, 서블릿 요청과 응답객체를 전달받아 결과를 응답 내의 결광 렌더링한다.
<<<스프링은 논리적 뷰 이름을 물리저인 뷰의 구현으로 변환하기 위한 13개의 뷰 리졸버를 제공한다>>>>>
1. BeanNameViewResolver: 뷰 이름과 같은 아이디를 갖는 스프링의 애플리케이션 컨텍스트의 빈으로 뷰를 결정한다.
2. ContentNegotiatingViewResolver: 클라이언트가 원하는 콘텐츠 타입을 고려하여 뷰를 결정하고, 그 타입을 만들 수 있는 다른 뷰 리졸버를 위임한다.
3. FreeMarkerViewResolver: FreeMarker 템플릿으로 뷰를 결정한다.
4. InternalResourceViewResolver: 웹 애플리케이션 내부의 리소스(일반적으로 JSP)로 뷰를 결정한다.
5. JasperReportViewResolver: JasperReports 정의로 뷰를 결정한다.
6. TilesViewResolver: 뷰 이름과 같은 ID를 가진 아파치 타일즈(Apache Tiles)로 뷰를 결정한다.
7. UrlBasedViewResolver: 뷰 이름과 일치하는 무리적인 뷰 정의로 직접 뷰를 결정한다.
8. VelocityLayoutViewResolver: 벨로시티(velocity) 템플릿들로 페이지를 구성하는 베로시티 레이아웃을 뷰로 결정한다.
9. VelocityViewResolver: 벨로시티 템플릿으로 뷰를 결정한다.
10. XmlViewResolver: XML파일로부터 빈 정의 뷰를 결정한다. BeanNameViewResolver와 유사하다.
11. XsltViewResolver: XLST변형 결과로 렌더링되는 뷰를 결정한다.
2. JSP뷰 만들기
스프링은 JSP를 아래의 두 가지 방식으로 지원한다.
컨트롤러의 요청-처리 로직과 뷰의 뷰-렌더링의 분리는 스프링 MVC의 중요한 기능이다.
컨트롤러 메소드가 직접적으로 HTML을 생성하게 된다면, 요청-처리 로직에 손을 대지 않고서는 뷰의 관리나 업데이트가 매우 어려울 거시다. 대부분 컨트롤러 메소드와 뷰의 구현은 모델의 내용에는 동일함이 있어야 한다. 하지만 컨트롤러가 단지 논리적인 이름으로만 뷰를 알 수 있다면, 스프링이 모델을 실제로 렌더링하기 위해 구현되어 있는 뷰를 어떻게 결정할까?
이것이 스프링의 뷰 리졸버의 역할이다.
InternalResourceViewResolver를 사용한다. 이 리졸버는 모델을 렌더링하게 될 뷰의 물리적인 위치로 전달되는 논리적 뷰 이름에 접두사(prefix)로 /WEB-INF/views/를 붙이고 접미사로(suffix)로 .jsp를 붙이도록 되어 있다.
스프링MVC는 다음과 같은 ViewResolver 인터페이스를 정의한다.
ResolveViewName()메소드는 뷰의 이름과 Locale를 넘겨 받고 View 인스턴스를 리턴해준다.
View인터페이스는 다음과 같다.
뷰 인터페이스 역할은 모델을 전달받는 것 뿐만아니라, 서블릿 요청과 응답객체를 전달받아 결과를 응답 내의 결광 렌더링한다.
<<<스프링은 논리적 뷰 이름을 물리저인 뷰의 구현으로 변환하기 위한 13개의 뷰 리졸버를 제공한다>>>>>
1. BeanNameViewResolver: 뷰 이름과 같은 아이디를 갖는 스프링의 애플리케이션 컨텍스트의 빈으로 뷰를 결정한다.
2. ContentNegotiatingViewResolver: 클라이언트가 원하는 콘텐츠 타입을 고려하여 뷰를 결정하고, 그 타입을 만들 수 있는 다른 뷰 리졸버를 위임한다.
3. FreeMarkerViewResolver: FreeMarker 템플릿으로 뷰를 결정한다.
4. InternalResourceViewResolver: 웹 애플리케이션 내부의 리소스(일반적으로 JSP)로 뷰를 결정한다.
5. JasperReportViewResolver: JasperReports 정의로 뷰를 결정한다.
6. TilesViewResolver: 뷰 이름과 같은 ID를 가진 아파치 타일즈(Apache Tiles)로 뷰를 결정한다.
7. UrlBasedViewResolver: 뷰 이름과 일치하는 무리적인 뷰 정의로 직접 뷰를 결정한다.
8. VelocityLayoutViewResolver: 벨로시티(velocity) 템플릿들로 페이지를 구성하는 베로시티 레이아웃을 뷰로 결정한다.
9. VelocityViewResolver: 벨로시티 템플릿으로 뷰를 결정한다.
10. XmlViewResolver: XML파일로부터 빈 정의 뷰를 결정한다. BeanNameViewResolver와 유사하다.
11. XsltViewResolver: XLST변형 결과로 렌더링되는 뷰를 결정한다.
2. JSP뷰 만들기
스프링은 JSP를 아래의 두 가지 방식으로 지원한다.
- InternalResourceViewResolver는 JSP파일에 뷰 이름을 결정하기 위해서 사용한다. JSP페이지의 JSTL(JavaServer Pages Standard Tag Library)을 사용하는 경우에 InternalResourceViewResolver는 JstlView에 의한 JSP파일로 뷰 이름을 결정하고, JSTL포맷과 메시지 태그에 JSTL로케일(locale)과 리소스 번들 변수를 대입한다.
- 스프링은 form-to-model바인딩을 위한 것과 일반적인 유틸리티 기능을 제공ㅎ는 두 개의 JSP태그 라이브러리를 제공한다.
3. JSP-ready 뷰 리졸버 설정하기
InternalResourceViewResolver는 접두사와 접미사를 붙이는 것으로 뷰의 이름을 결정한다.
/WEB-INF/views/==접두사
home==논리적인 뷰 이름
.jsp== 접미사
@Bean 애너테이션이 붙어 있는 메소드에서 다음과 같이 설정하면 InternalResourceViewResolver가 뷰를 결정할 때 위와 같은 규칙이 적용된다.
*선택적으로 스프링의 XML기반 설정을 사용하고 싶다면 InternalResourceViewResolver를 아래와 같이 설정한다.
<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver"
p:prefix="/WEB-INF/views/"
p:suffix=".jsp"/>
논리적 뷰 이름에 슬래시(/)가 있는 경우, 그것이 리소스 패스 이름을 전달하게 된다. 그러므로 이것은 접두사의 프로퍼티에 의해 참조되는 어떠한 서브 디렉토리 안에 있는 JSP파일을 매핑한다. 이러한 점은 뷰 템플릿들을 단일 디렉토리가 아닌 계층적인 디렉토리로 관리하는 것을 용이하게 한다.
3. 스프링의 JSP라이브러리 사용하기
태그 라이브러리는 스크립틀릿 블록에 직접 자바코드를 작성할 필요 없이 JSP템플릿에 기능을 추가하는 강력한 방법이다. 스프링은 스프링 MVC웹 뷰의 정의를 용이하게 하는 두 가지 JSP태그 라이브러리를 제공한다.
<**폼에 모델 바인딩하기**>
대부분 HTML 폼태그를 렌더링한다. 이 태그들이 HTML 태그들과 다른 점은 모델의 객체로 바인딩된다는 점과 모델 객체의 프로퍼티로부터 값이 입력되는 것이 가능하다는 점이다. 또한 태그라이브러리는 사용자에게 오류를 전달하는 것이 가능한데, 이것은 결과 HTML에 렌더링되어 표시된다.
폼바인딩 택를 사용하기 위해서 JSP페이지 안에 아래의 내용을 선언한다.
<%@ taglib uri="http://www.springframework.org/tags/form" prefix="sf" %>
여기서 sf는 Spring Forms의 축약어이다.
예)
**JSP안에 다음과 같이 작성한다**
<sf:form method="POST" commandName="spitter">
First Name: <sf:input path="firstName" /><br/>
Last Name: <sf:input path="lastName" /><br/>
Email: <sf:input path="email"/><br/>
UserName:<sf:input path="username"/><br/>
Password:<sf:password path="password"/><br/>
<input type="submit" value="Register"/>
</sf:form>
---><sf:form>태그는 HTML<form>태그를 렌더링 한다. 그리고 이 태그는 commandName애트리 뷰트에 지정되는 모델 객체의 컨텍스를 설정한다.
이전의 코드에서 commandName을 spitter에 설정하였다. 그래서 객체가 키가 spitter인 모델에 있어야 하고, 아니라면 폼은 (JSP 에러와 함께)렌더링을 실패한다. 이는 모델의 Spitter객체가 spitter키 모델을 참조하여, SpitterController변경을 해야 한다는 의미를 가진다.
@RequestMapping(value="/register", method=GET)
public String showRegistrationForm(Model model)
{
model.addAttribute(new Spitter());;
return "registerForm";
}
<오류 표시하기>
예로 <sf:errors>가 registerFrom.jsp의 스니펫에서 어떻게 사용되는지 보여준다.
<sf:form method="POST" commandName="spitter">
First Name: <sf:input path="firstName"/>
<sf:errors path="firstName"/><br/>
.....
</sf:form>
댓글
댓글 쓰기