JavaServer Faces 라이프 사이클
JavaServer Faces(JSF) 라이프 사이클은 꽤나 긴 내용이기 때문에 라이프 사이클 각 단계(phase)별로 나눠서 작성 하도록 하겠습니다.
어플리케이션의 라이프 사이클은 해당하는 어플리케이션 처리의 여러 단계이며 시작과 끝을 의미한다. 모든 어플리케이션은 라이프 사이클이 있습니다. 어플리케이션의 라이프 사이클 동안 일반적인 작업은 다음의 내용을 포함하여 실행 됩니다.
- 들어오는 요청을 처리
- 파라메터의 디코딩
- 상태를 수정 및 저장
- 웹 브라우저에 웹 페이지를 랜더링
JSF 웹 어플리케이션 프레임워크는 간단한 어플리케이션을 위해 라이프 사이클의 각 단계를 자동으로 관리 하거나 필요에 따라 복잡한 어플리케이션에 대해서는 수동으로 관리 할 수 있습니다.
고급 기능을 사용하는 JSF 어플리케이션은 특정 단계에서 라이프 사이클과의 상호 작용이 필요합니다.
예를 들어 Ajax 어플리케이션은 라이프 사이클의 부분 처리 기능을 사용합니다. (참조 : Partial Processing and Partial Rendering)
라이프 사이클의 명확한 이해는 잘 디자인된 컴포넌트를 만드는 핵심이 됩니다.
기본적으로 JSF 웹 어플리케이션은 실행 단계와 랜더링 단계 두 가지 주요 단계로 구성 됩니다. 이번 글에서는 JSF 어플리케이션의 라이프 사이클에 대하여 더 자세히 알아보겠습니다.
JSF 라이프 사이클의 개요
JSF 어플리케이션의 라이프 사이클은 클라이언트의 요청(request)으로 시작하여 서버가 응답(response) 페이지를 HTML 로 변환 하면서 종료 됩니다.
라이프 사이클은 실행(execute)과 랜더(render) 의 두가지 주요 단계로 나눌 수 있습니다. 실행 단계에서는 더 정교한 컴포넌트 트리를 지원하는 하위단계로 나누어집니다. 이러한 구조는 컴포넌트 데이터의 변환(convert)과 검증(validate), 컴포넌트 이벤트의 처리, 그리고 컴포넌트 데이터가 규칙적으로 빈(bean) 들에 전달 될 것을 요구 합니다.
JSF 페이지는 컴포넌트들의 트리로 나타나며 뷰(view) 라고 합니다. 라이프 사이클 동안 JSF 구현체는 뷰를 만들때 페이지를 제출 하기 이전에 상태(state)를 저장할지 고려 해야 합니다. 클라이언트가 페이지를 요청할때 JSF 구현체는 뷰의 컴포넌트에 입력된 데이터의 검증과 입력 데이터를 서버측(server side)에 지정된 특정 타입으로 변환 작업등을 수행해야 한다.
JSF 구현체는 JSF 요청에서 응답까지 라이프 사이클의 모든 단계의 작업을 수행해야 합니다. 다음 그림은 라이프 사이클의 단계를 보여줍니다.
<JSF 요청에서 응답까지 표준 라이프 사이클>
요청-응답 라이프 사이클은 두가지 종류의 요청이 있습니다. 최초 요청과 포스트백. 최초 요청(initial request) 는 사용자가 처음으로 페이지를 요청하면 발생합니다. 포스트백 요청은 최초 요청에 의해 실행 된 결과가 브라우저에 이미 로드가 된 페이지의 폼을 사용자가 제출(submit)을 하면 발생 합니다.
라이프 사이클이 최초 요청을 처리 할때는 오직 뷰 복원과 응답을 랜더링하는 단계가 실행됩니다. 왜냐하면 최초 요청에는 유저의 입력이나 액션 처리가 없기 때문입니다. 라이프 사이클이 포스트백을 처리 할 때에는 반대로 모든 단계가 실행 됩니다.
보통은 클라이언트의 첫번째 JSF 페이지 요청은 JSF 페이지의 링크나 버튼 컴포넌트를 클릭한 결과입니다. 이것은 또 다른 JSF 페이지를 랜더링 하여 응답하는것이며 이 어플리케이션은 들어오는 요청과 응답을 생성하여 처리하는것과 관계가 있는 javax.faces.context.FacesContext 인스턴스 내부에 새로운 뷰를 만들고 저장합니다. 그런 뒤 어플리케이션은 뷰가 필요로 하는 객체의 레퍼런스를 취득하고 FacesContext.renderResponse 메소드를 호출하여 즉시 라이프 사이클의 랜더 응답 단계로 건너띄어 뷰를 강제로 랜더링 하며 위 그림에서 화살표로 표시 되어 있습니다.
가끔 어플리케이션은 웹서비스와 같은 다른 웹 어플리케이션 리소스로 리디렉션(redirect) 또는 JSF 컴포넌트를 포함하지 않는 응답을 랜더링 해야 할 수도 있습니다. 이러한 상황에서 개발자는 FacesContext.responseComplete 메소드를 호출 하여 응답을 랜더링하는 단계를 생략 하면 됩니다. 이 상황은 또한 위 그림에서 Response Complete 의 화살표를 나타냅니다.
가장 일반적인 상황은 JSF 컴포넌트가 다른 JSF 페이지에 대한 요청을 서밋 하는 것입니다. 이 경우에는 JSF 구현체가 요청을 처리하고 라이프 사이클 내부의 단계를 통해 모든 필요한 변환들, 검증들 그리고 모델을 업데이트 하고 응답을 생성하는 작업을 수행합니다.
여기서 설명한 라이프 사이클에 대한 한가지 예외가 있습니다. 컴포넌트의 immediate 속성 값이 true 로 설정 되었을때 이러한 컴포넌트와 관련된 검증, 변환, 이벤트가 요청값 적용 단계 (Apply Request Values Phase) 보다 이후 단계에서 처리 됩니다.
개발자를 위한 검증, 변환, 이벤트를 일반적으로 처리 하는 방법과 변화를 어떻게 언제 처리하는지 라이프 사이클에 대한 더 자세한 설명을 다음 블로그에서 작성 하도록 하겠습니다.
출처
'공부 > JSF' 카테고리의 다른 글
| Managed bean 스코프에 대하여 (0) | 2014.10.06 |
|---|---|
| JSF 라이프 사이클 상세 (0) | 2014.10.06 |
| JSF 어플리케이션 Hello World 예제 (0) | 2014.10.04 |
| JavaServer Faces 어플리케이션 개발 준비 (0) | 2014.10.04 |
| Facelets 란 무엇인가? (0) | 2014.10.02 |
