2장 JSF 요청 처리 생명주기 – Phase 2. 요청 값 적용하기

Apply Request Values

- 사용자 입력을 받는 컴포넌트들은 사용자가 입력한 원래 데이터를 나타내는 submitted value를 가지고 있다.
– 프레임워크가 요청의 매개변수를 기반으로 submitted value를 설정해준다.
– 이 과정을 decoding이라 부른다.
– 각 컴포넌트는 자신의 id와 자신을 감싸고 있는 컴포넌트의 id를 이용해서 client identifiter를 만든다.
– 이 단계에서 컴포넌트의 요청에 자신의 client id에 해당하는 매개변수가 있는지 확인하여 있다면 그 매개변수의 값으로 설정한다.
– 컴포넌트의 immediate 속성을 true로 설정하면 검증 단계에서 하지않고 그 즉시 검증을 실행한다.
– 이 단계에서 액션 이벤트를 만들 수도 있다. 만들어진 이벤트는 FacesContext에 추가되고 나중에 ‘애플리케이션 호출’ 단계에서 사용된다.
– 이 단계가 끝난뒤 존재하는 이벤트를 관련 리스너로 전달한다.
– 모든 랜더러, 컴포넌트, 리스너는 생명주기를 단축시켜 이 단계를 건너뛰거나 바로 최종단계로 넘어갈 수도 있다.
– 또는 각각의 입력 컴포넌트가 적절하게 디코딩된 속성을 가지고 현재 요청에 기반한 최신 값을 가지고 있을 것이다.

2장 JSF 요청 처리 생명주기 – Phase 1. 뷰 복원하기

Restore View

- 뷰는 특정 페이지를 구성하는 모든 컴포넌트를 나타낸다. 
- 브라우저 위에 히든 필드를 이용해서 클라이언트에 저장될 수도 있고, 세션을 이용해서 서버에 저장될 수도 있다. 서버에 저장되는게 기본값이다.
- 각각의 뷰는 컴포넌트 트리로 구성되며 고유의 식별자를 가지고 있다. 그 식별자를 “뷰 식별자”라고 한다. View identifier
- 뷰 식별자는 요청에서 특수한 경로에 해당한다. 서블릿 경로 이후의 값이 뷰 식별자가 된다. 예) http://spirngsprout.org/study/35.do 에서 /study/35.do
- 폼을 보여준 페이지와 동일한 페이지로 다시 포스팅 요청을 하는 것을 포스트백(postback)이라고 한다.
- 기존의 프레임워크와 차이: “이 액션을 수행하라.” VS “사용자가 이 명령을 실행했다.”, “사용자가 이 컨트롤의 값을 변경했다.”
- 이때 중요한 것은 최종 페이지가 어떤 것이며, 그곳에서 어떤 이벤트가 발생했는냐 이다.
- 현재 뷰를 찾아서 사용자가 입력한 내용을 거기에 적용하는 것이 이 단계의 주요 작업 중 하나이다. 
– 세션에서 뷰를 찾아 본 뒤에 뷰가 있으면 그것을 가져와서 FacesContext에 저장하고, 없으면 새로 요청한 뷰 식별자를 기반으로 새로운 뷰를 만들어서 FacesContext에 저장한다.
- 뷰를 복원하는 단계에서 컴포넌트의 값은 물론이고 그와 관련된 이벤트 리스너, 검증기, 변환기도 복원됐는지 확인한다.
- 백빈의 속성에 바인딩되어 있는 컴포넌트의 경우에는 이 단계에서 백빈의 속성과 컴포넌트가 동기화된다.
- 브라우저가 보낸 HTTP 요청의 헤더를 통해 뷰에 사용할 언어를 설정한다.
- 요청이 포스트백일 경우에는 다음 단계로 넘어가고, 그외의 경우에는 처리할 사용자 입력이 없기 때문에 응답 랜더링(Render Response) 단계로 넘어간다.
 

2장 JSF 기본 – 요청 처리 생명주기

뷰 복원하기(restore view) – 선택한 뷰에대한 컴포넌트 트리를 찾거나 만드는 단계.  HtmlCommandButton 같은 컴포넌트에서 액션 이벤트를 발생 시킨다.

요청 값 적용하기(Apply Request Values) – 컴포넌트의 값들을 요청에 담겨있는 값과 동일하게 맞춘다. 이 과정에서 변환기(Converter)가 사용될 수 있으며,  변환시 에러가 발생하면 변환 에러를 추가한다.
검증 수행(Process Validations) – 모든 컴포넌트가 각자 검증을 수행하도록 지시한다. 검증 에러 메시지가 보고될 수 있다.
모델 값 갱신(Update Model Values) – 컴포넌트에 연결된 백빈(backing bean) 또는 모델 객체의 값을 갱신한다.  변환 에러가 보고 될 수 있다.
애플리케이션 호출(Invoke Application) – 등록된 액션 리스너를 호출한다. 
응답 랜더링(Render Response) – 선택한 뷰를 보여준다.

2장 JSF 기본 – 주요 구성 요소

UI 컴포넌트(컨트롤 또는 그냥 컴포넌트라고 부르기도 함) – 상태를 유지하는 객체다(stateful object). UI 컴포넌트는 자바빈으로 프로퍼티, 메서드, 이벤트를 가지고 있다. UI 컴포넌트는 뷰를 구성하며, 보통 컴포넌트 트리가 한 페이지를 보여준다.

랜더러(renderer) – UI 컴포넌트를 보여주며 사용자 입력값을 컴포넌트의 값으로 변환하는 책임을 가지고 있다. 랜더러는 한개 또는 여러개의 UI 컴포넌트를 다룰 수 있으며 한개의 UI 컴포넌트가 여러개의 다른 랜더러에 의해 처리될 수 있다.

검증기(validator) – 사용자가 입력한 값을 수용할 수 있는지 검사한다. 한 개의 UI 컴포넌트가 여러개의 검증기에 의해 처리될 수 있다.

백빈(backing bean) – UI 컴포넌트에서 값을 수집하며 이벤트 리스너 메소드를 구현하는 자바빈이다. UI 컴포넌트에 대한 레퍼런스도 가질 수 있다.

변환기(converter) – 컴포넌트의 값을 화변에 보여줄 문자열로 변환하고 그 반대로도 변환해준다. 한 개의 UI 컴포넌트에는 한 개의 컨버터만 적용된다.

이벤트와 리스너(events and listners) – JSF는 자바빈 이벤트/리스너 모델을 사용한다. UI 컴포넌트는 이벤트를 발생시키며 리스너를 등록할 수 있다.

메시지(message) – 사용자에게 다시 보여줄 정보. 백빈, 검증기, 컨버터 등에서 사용자에게 보여줄 메시지나 에러 메시지를 생서앟ㄹ 수 있다.

네비게이션(nvigation) – 어떤 페이지에서 다른 페이지로 이동하는 기능. JSF는 특화된 이벤트 리스너와 연동된 강력한 네비게이션 시스템을 가지고 있다.

1장 JSF 소개 – Introducing JavaServer Faces

1.1 JSF는 무엇인가?

JSF는 RAD 툴의 4계층 중에 셋으로 컴포넌트 아키텍처, UI 위젯 표준 집합, 애플리케이션 인프라를 정의한 것이다. JSF 컴포넌트 아키텍처는 UI 위젯을 만드는 일반적인 방법을 정의한다.

1.2 기반 기술

HTTP – 텍스트 헤더 기반의 간단한 프로토콜로 클라이언트가 요청을 서버는 요청한 문서를 브라우저로 보내준다. HTTP는 “stateless” 프로토콜이다. 클라이언트의 여러 요청에 대한 정보를 기억하지 못한다.

Servlet – HTTP는 정적인 페이지를 보여줄 때 매우 좋다. 동적인 페이지를 만들려면 코딩이 필요하다. HTTP가 간단하긴 하지만 헤더를 파싱해서 뭘 원하는지 알아야 하고 다시 또 적절한 형식으로 헤더를 만들어야 하는 불편한 코딩을 객체 지향적으로 할 수 있게 서블릿 API를 제공한다. 즉 HTTP 요청과 응답을 객체로 캡슐화하고 Servlet에서 요청을 처리한다.

Portlet – 패스

JavaBean – 강력한 이벤트 모델을 가지고 있다.

1.4 컴포넌트

JSF는 UI 컴포넌트 또는 컨트롤을 제공한다.

1.5 Hello, world!


인텔리에서 해봤는데 JSF 개발하는데 아무 지장 없을 듯.
faces-config.xml 파일 작성할 때 자동완성 지원 귿.