Tagged

JSF

A collection of 18 posts

클라이언트 식별자

2장 컴포넌트 식별자와 클라이언트 식별자

– UI 컴포넌트는 서버에서는 컴포넌트 트리로 살고 클라이언트쪽에서는 여러 형태의 뷰 표현체로 존재한다. – 서버쪽에서는 컴포넌트 식별자로 컴포넌트를 참조한다. – 클라이언트에서는 클라이언트 식별자를 사용해서 컴포넌트를 참조한다. – 컴포넌트 식별자를 이용해서 클라이언트 식별자를 생성한다. – 컴포넌트 식별자는 반드시 문자 또는 언더바(_)로 시작한다. – 컴포넌트 식별자를 생략하면 JSF가 자동으로 만들어 준다.
요청 처리 생명주기

2장 JSF 요청 처리 생명주기 - Phase 6. 응답 보여주기

Render Response – 최종적으로 사용자에게 응답을 보낸다. – 뷰 상태를 저장하여 ‘뷰 복원하기’ 단계에서 재사용할 수 있게 한다. – 특정 뷰 기술에 종속적이지 않다. – 컨트롤러의 인코딩 메서드 결과만을 뷰에서 사용할 수 있다. – 컨트롤러의 인코딩 메서드 결과를 마크업을 만드는 애플리케이션에서 통합할 수 있다. – 컨트롤러의 인코딩 메서드
애플리케이션 호출하기

2장 JSF 요청 처리 생명주기 - Phase 5. 애플리케이션 호출하기

Invoke Application – 이 단계에서 등록되어 있는 리스너로 이벤트를 전파한다. – ‘요청값 적용하기’ 단계에서 만든 액션 이벤트를 여기서 전파한다. – 컴포넌트에 등록된 액션 리스너 EL을 평가하여 백빈의 특정 메서드(액션 리스너 메서드)를 실행한다. – 액션 리스너 메서드는 컴포넌트의 actionListener 속성으로 설정한다. – 액션 리스너 메서드 실행이 끝나면
검증하기

2장 JSF 요청 처리 생명주기 - Phase 3. 검증하기

Process Validation – 이 단계에서 JSF는 컴포넌트 트리를 순회하면서 각각의 컴포넌트에게 자신의 값을 수용할 수 있는지 확인하도록 요청한다. – ‘요청 값 적용하기’ 단계에서 입력 컴포넌트들이 갱신되기 때문에 이 단게에서는 사용자가 입력한 최신값을 가지고 있다. – 검증을 하기전에 변환기에 의해 값이 변환된다. – 변환기와 검증기를 무사히 거치고 나면 해당
요청 값 적용하기

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

Apply Request Values – 사용자 입력을 받는 컴포넌트들은 사용자가 입력한 원래 데이터를 나타내는 submitted value를 가지고 있다. – 프레임워크가 요청의 매개변수를 기반으로 submitted value를 설정해준다. – 이 과정을 decoding이라 부른다. – 각 컴포넌트는 자신의 id와 자신을 감싸고 있는 컴포넌트의 id를 이용해서 client identifiter를 만든다. – 이 단계에서 컴포넌트의 요청에 자신의
JSF

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

Restore View – 뷰는 특정 페이지를 구성하는 모든 컴포넌트를 나타낸다.  – 브라우저 위에 히든 필드를 이용해서 클라이언트에 저장될 수도 있고, 세션을 이용해서 서버에 저장될 수도 있다. 서버에 저장되는게 기본값이다. – 각각의 뷰는 컴포넌트 트리로 구성되며 고유의 식별자를 가지고 있다. 그 식별자를 “뷰 식별자”라고 한다. View identifier
요청 처리 생명주기

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

뷰 복원하기(restore view) – 선택한 뷰에대한 컴포넌트 트리를 찾거나 만드는 단계.  HtmlCommandButton 같은 컴포넌트에서 액션 이벤트를 발생 시킨다. 요청 값 적용하기(Apply Request Values) – 컴포넌트의 값들을 요청에 담겨있는 값과 동일하게 맞춘다. 이 과정에서 변환기(Converter)가 사용될 수 있으며,  변환시 에러가 발생하면 변환 에러를 추가한다. 검증
번역

SWF 12장 JSF 통합

12.1. 도입 스프링 Faces는 스프링의 JSF 통합 모듈로 스프링에서 JSF 사용을 간편하게 해준다. JSF UI 컴포넌트 모델을 스프링 MVC와 스프링 웹 플로우 컨틀로러와 함께 사용할 수 있게 해준다. 스프링 Faces는 또한 Ajax와 클리이언트쪽 검증 기능을 제공하는 자그마한 Facelets도 제공한다. 이 컴포넌트 라이브러리는 스프링 자바스크립트를 기반으로 만들었다. 스프링 자바스크립트는 Dojo를
스프링 MVC

Validator에도 여러 가지가 있네

JSF 스캐(스크린캐스팅)를 찍다가 알게 된건데, 기본 검증기, Application-level 검증, 커스텀 검증기, 표준 검증기가 있었습니다. 기본 검증기는 프레임워크에서 제공하는 것으로 JSF에는 길이 검사라던가, 숫자가 최소치와 최대치 사이의 값인지 범위를 검사할 수 있는 기본 Validator들을 제공하고 있었습니다. 스프링 MVC는 어떨까요? 글쎄요. 없는 것 같네요. ValidationUtils는 있지만 JSF 처럼 간단하게 뷰에서
JSF

Spring Faces 소개하기, 파트 1

참조, 요약, 번역: http://www.jsfcentral.com/articles/intro_spring_faces_1.html JavaServer Faces와 스프링의 연동을 돕는 Spring Faces라는 모듈이 있는데, 이 모듈을 Spring Web Flow 2에 도입했다. 본 기사는 Spring Faces에 대한 첫 번째 기사로, JSF 기준과 Spring 기준으로 각각 두 프레임워크를 통합하는 방법을 살펴볼것이다. 스프링은 예전부터 기본적인
JSF

JavaServer Faces 시작하기 Part 1 Building basic applications

참조 : http://www.ibm.com/developerworks/edu/j-dw-java-jsf1-i.html JSF가 제공하는 장점• Clean separation of behavior and presentation• Component-level control over statefulness• Events easily tied to server-side code• Leverages familiar UI-component and Web-tier concepts• Offers multiple, standardized vendor implementations• Excellent IDE support JSF 애플리케이션 구성 요소• JavaBeans for managing application
라이프사이클

JSF 기초 2

참조 : JSF for nonbelievers: The JSF application lifecycle JSF 라이프사이클 1. Restore view 요청이 FacesSevlet으로 전달되면, 컨트롤러는 요청을 분석해서 뷰 ID를 뽑아낸다. (JSP 페이지 이름을 바탕으로) JSF 프레임워크 컨트롤러는 뷰 ID를 사용해서 현재 뷰에서 사용할 컴포넌트들을 가져온다. 뷰가 없으면, 새로 만들어서 사용한다. 만약에 뷰가 이미 있으면, 그것을 사용한다. 뷰에는 모든
JSF

불신자를 위한 JSF 시리즈

JSF for nonbelievers: Clearing the FUD about JSFJSF for nonbelievers: The JSF application lifecycleJSF for nonbelievers: JSF conversion and validationJSF for nonbelievers: JSF component development 외국에선 상당히 많은 개발자들이 사용하고 있다는 JSF.. 저도 한 번 써보고 싶어서 공부를 시작합니다. 위에 두 개의 아티클은 한국 IBM DeveloperWorks에 번역된 기사를 찾긴 했는데,