MVC 모델 1의 한계 ->client 측이 device가 다양화(pc, android, ios 등) 됨 -> 요구하는 응답 데이터의 포맷(pc -> HTML, CSS, JS/ 모바일-> XML, JSON/ 기타 ->PDF, JPEG)이 다양해졌다. -> 해결책 : MVC 모델2의 등장
한계 -> 데이터 포맷을 요청하고 응답하는 것 마다 jsp 를 따로 만들어야함
서비스 객체를 사용하기 전에 입력 데이터를 가공하는 코드, 출력할데이터를 준비하는 코드, 서비스 객체를 호출하는 코드가 중복된다.
해결책 -> client가 보낸 입력 데이터 가공 및 검증, 서비스 객체 실행, 출력 데이터 준비, 실행시킬 뷰 객체 선택 controller 를 통해서 어떤 view 를 실행할지 통제한다. view의 역할은 온전히 출력할 데이터를 가공하는 일에만 집중한다.
controller는 service를 호출하는 일을 함
requestDispatcher 는 요청배달자임
error 가 뜨면 error.jsp 로 보내버림
controller 는 error를 띄우지 않음 error는 jsp에게 맡김
MVC 모델2 에서는 모든 요청을 controller 가 받도록 해야함
JSP 액션태그 -> 자바코드를 생성하는 태그
<jsp : 태그명 속성명="값" ...></jsp : 태그명> --(생성)--> 자바 코드
namespace : 태그가 소속된 그룹, 자바의 패키지와 유사한 역할
ex)
<jsp:useBean id="totalPageSize" type="java.lang.Integer" scope="request"></jsp:useBean> --(생성)-->request.getRequestDispatcher("url").include()
<jsp:useBean id="객체명(ex)list)" type="클래스(java.util.List)" scope="request"></jsp:useBean>
==(jsp 액션태그가 미리 정의된 자바 코드로 바뀌는 과정)=> java.utilList list = (java.util.List)request.getAttribute("list");
if (list == null ) {
list = (List) new ArrayList();
requset.setAttribute("list", list);
}
type 이랑 class랑 같음 내부코드로 가게되면 type의 경우 객체를 생성해주고 class의 경우 바로 사용함
// Servlet API 라이브러리
// => 컴파일 할 때만 사용하고, 배포할 때는 제외할 라이브러리(providedCompile)
providedCompile 'javax.servlet:javax.servlet-api:4.0.1'
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
=> prefix 값은 c로 줘야지 유지보수에 좋음
뭐.뭐.뭐 <= OGNL 표기법 사용해서 객체의 getter 호출
Object Graph Navigation Language
pageScope 는 보관소 명 => 안써도 상관없다.
jstl 은 expression language 가 아님
