
IBM
WebSphere Portlet Factory 8.0.0 문서


초판
2012년 5월 발행

© Copyright IBM Corporation 1993, 2012


초판
2012년 5월 발행

© Copyright IBM Corporation 1993, 2012
접근성에 관하여 IBM이 약정한 내용에 따라 이 제품 문서에 접근이 가능합니다.
이 HTML 파일은 이번 릴리스에 관한 공식적인 제품 문서의 최신 초안을 포함합니다. 필요에 따라 분기별로 이 초안을 새로 고칩니다. 최신 제품 문서 업데이트에 관한 내용은 위키의 제품 문서 섹션에서 릴리스 전용 기사를 참조하십시오.
사용자 브라우저에서 이 문서의 로컬 사본을 저장할 수 있습니다. 각 브라우저마다 다른 메뉴 및 메뉴 옵션이 있습니다. 이 문서의 로컬 저장 시 도움이 필요한 경우 브라우저 도움말을 참조하십시오.
이 문서에 대한 피드백을 제공하려면 Lotus 문서 피드백 웹 사이트를 참조하십시오.
이 주제에는 Web Experience Factory 학습 자원에 대한 추가 링크가 나열되어 있습니다.
Web Experience Factory Designer는 Eclipse 기반 개발 환경으로 통합되었습니다.
Web Experience Factory Designer는 IBM Lotus Mashup에 공개할 J2EE(Java 2 Platform, Enterprise Edition) 웹 애플리케이션, 포틀릿 및 위젯 개발용 도구입니다.
Web Experience Factory Designer는 Eclipse 기반 통합 개발 환경(IDE)에 대한 플러그인입니다.Eclipse의 Web Experience Factory 퍼스펙티브에서 작업하여 프로젝트를 작성하며 여기서 빌더 및 프로파일 세트를 사용하여 모델을 개발하고 이러한 모델에서 결과 웹 애플리케이션을 생성합니다.
각 빌더는 입력을 지정하도록 안내하는 마법사 사용자 인터페이스가 있습니다. 빌더는 애플리케이션의 일부를 자동으로 생성하거나 수정합니다. 프로파일 세트의 프로파일을 사용하면 하나의 애플리케이션을 조정하여 여러 버전을 생성할 수 있습니다. 예를 들면, 서로 다른 언어 또는 서로 다른 사용자 그룹에 각각 다른 버전을 생성할 수 있습니다.
사용자 인터페이스 또는 데이터 서비스를 구현하려면 모델에서 빌더를 수집하십시오. 모델에 있는 빌더의 입력에 변경을 수행한 경우 애플리케이션 코드가 다시 생성됩니다. 재생성을 통해 애플리케이션을 반복해서 개발할 수 있습니다. 빌더는 JSP, Java 클래스 및 XML 문서 등의 필요한 애플리케이션 코드를 생성합니다. 반복적 개발을 용이하게 수행하려면 설계 패턴을 구현하는 빌더를 사용하십시오.
IBM WebSphere® Portal 서버 프레임워크는 여러 서비스(예: 페이지 탐색 및 협업 기능)를 제공합니다.
또한 Web Experience Factory Designer는 새 빌더 및 프로파일의 작성을 용이하게 합니다.
Web Experience Factory 위키에서는 설치 및 애플리케이션 개발에 대한 추가 정보를 찾을 수 있습니다. 이 위키는 매우 동적이므로 정기적으로 확인해야 합니다.
전문 지식을 공유하십시오! 등록한 다음 이 활동적인 개발자 커뮤니티에 참여하십시오.
Web Experience Factory Designer는 모든 기능 및 함수에 대한 해당 도움말을 제공합니다. 여러 가지 방법으로 도움말에 액세스할 수 있습니다.
모든 Web Experience Factory Designer 창 및 대화 상자는 창 또는 대화 상자에서 지원되는 태스크를 설명하는 해당 도움말을 제공합니다. 이 도움말을 보려면 컨텍스트를 설정하는 창 또는 대화 상자에 초점을 맞춘 후 F1 키를 누르십시오.
빌더 호출 편집기는 빌더의 구성 도움말에 액세스하기 위해 사용할 수 있는 도움말 단추를 제공합니다.
Web Experience Factory는 Eclipse 도움말 시스템에 문서 플러그인을 설치합니다. 이 플러그인은 Eclipse 도움말 엔진의 컨텍스트 내에서 실행되고 Eclipse 도움말 메뉴에서 액세스될 수 있습니다. Web Experience Factory 도움말에 액세스하려면 Eclipse에서 를 클릭하십시오. Eclipse SDK 도움말 창이 열립니다. 왼쪽 분할창의 컨텐츠에서 IBM Web Experience Factory Designer를 클릭하면 오른쪽 분할창에 소개 페이지가 표시됩니다.
해당 버전의 IBM Web Experience Factory에는 여러 새로운 기능이 있습니다.
프로젝트에 기능 세트()를 추가하여 리치 기본 룩앤필을 사용하는 경량 모바일 웹 애플리케이션 개발을 지원할 수 있습니다.
더 이상 사용되지 않는 빌더에 대한 도움말에 있는 정보에는 더 이상 사용할 수 없는 이 빌더에 대한 대체(가능한 경우)로 사용할 수단이 제시됩니다.
다음 기능이 Web Experience Factory Designer에 추가되었습니다.
Web Experience Factory 버전 8.0를 사용할 수 있습니다.
Web Experience Factory 버전 8.0에서 해결된 APAR 목록은 다음 위치에 있는 수정사항 목록을 참조하십시오.
하드웨어 및 소프트웨어 호환성에 대한 정보는 다음 위치에서 자세한 시스템 요구사항 문서를 참조하십시오.
단계별 설치 지침은 Information Center의 다음 주제를 참조하십시오.
알려진 문제점은 다음 위치에 있는 IBM 지원 포털에 문서화되어 있습니다.
http://www.ibm.com/support/entry/portal/Overview/Software/Lotus/IBM_Web_Experience_Factory
문제점이 발견되고 해결되면 IBM 지원 팀에서 지식 기반을 업데이트합니다. 지식 기반을 검색하면 문제 해결 방법 또는 솔루션을 신속하게 찾을 수 있습니다.
다음 링크를 클릭하면 지원 지식 기반의 사용자 정의된 조회를 시작할 수 있습니다.
Web Experience Factory 8.0에 대해 잘 알려진 문제점 모두 보기
Web Experience Factory에서 포털 개발 팀을 위해 수행할 수 있는 작업을 찾습니다.
Web Experience Factory는 SOA(Service Oriented Architecture) 위에 빠르게 포틀릿을 빌드하기 위한 강력하고 유연한 도구입니다. 자동으로 개발자를 높은 가치의 사용자 정의 포틀릿으로 어셈블하여 개발자가 회사의 핵심 자산을 빠르고 쉽게 이용할 수 있습니다. Web Experience Factory를 사용하여 작성된 포틀릿은 동적이며 안정된 J2EE(Java 2 Enterprise Edition) 애플리케이션입니다. 이 애플리케이션은 자동으로 변경사항에 대응하며 비즈니스 사용자가 실시간으로 수정할 수 있으므로 자산을 코딩, 복제 또는 버전 작성할 필요 없이 변경되는 비즈니스 요구사항을 충족시킬 수 있습니다. 이러한 구현과 구현의 변형 모두를 코딩할 필요없이 Web Experience Factory가 개발, 공개 및 변경 관리 프로세스를 단순화하여 회사 시간 및 비용을 절약합니다.
Web Experience Factory의 기본 기능은 다음과 같습니다.
이 섹션에서는 아키텍처로 시작하여 Web Experience Factory의 기술 개요를 제공합니다.
아키텍처 스택의 첫 번째 레이어는 데이터 소스입니다. 데이터는 데이터베이스, 엔터프라이즈 애플리케이션(예: SAP), 협업 플랫폼(예: Domino) 및 SAP Business Warehouse와 같은 제품의 히스토리 또는 분석 데이터를 포함한 여러 다른 시스템을 소스로 할 수 있습니다.
다음 두 레이어(서비스 및 포틀릿)는 둘 다 Web Experience Factory Designer를 사용하여 개발할 수 있습니다. Designer 도구는 Eclipse 플러그인이며 IBM Rational® Application Developer와 같은 Eclipse 기반 제품에서 원활하게 실행됩니다.
마지막 레이어는 WebSphere Portal Server 프레임워크이며, 이는 페이지 탐색 및 작성 도구, 싱글 사인온 기능, 사용자 관리, 기본 제공 프로세스 서버 및 협업 기능(예: 인스턴스 메시징)과 같은 주요 서비스를 제공합니다.
개발자는 Web Experience Factory를 사용하여 빌더라는 일련의 컴포넌트를 함께 묶어 포틀릿을 빌드합니다. 각 빌더는 마법사와 비슷한 단순 사용자 인터페이스를 포함하며 애플리케이션 파트를 자동으로 생성하거나 수정하는 작업을 수행합니다. 빌더는 애플리케이션 디자인 패턴을 구현합니다.
빌더는 모델로 어셈블되며 모델은 애플리케이션 생산 라인과 유사합니다. 모델의 빌더가 변경될 때마다 애플리케이션 코드가 재생성되어 개발자가 반복적으로 사용자 정의 포틀릿 애플리케이션을 개발할 수 있습니다. 일부 빌더는 웹 애플리케이션 아티팩트(예: 페이지 또는 테이블)를 작성하는 반면 다른 빌더는 열 재배열, 숨기기 또는 테이블에 추가를 통해 이전 빌더에서 작성된 아티팩트를 수정합니다. 빌더는 JSP, Java 클래스 및 XML 문서를 포함한 모든 애플리케이션 코드를 생성합니다.
또한 개발자는 추가로 코드를 변경하거나 다시 공개할 필요없이 한 코드 기반에서 여러 포틀릿 변형을 작성할 수 있습니다. 이는 Web Experience Factory의 프로파일링 기술을 사용하여 수행합니다. 영역, 역할 또는 그룹 멤버십과 같은 특성에 따라 다른 사용자 구성소에 대해 다른 프로파일을 작성할 수 있습니다. 또한 프로파일링 기술은 비즈니스 사용자가 단순 브라우저 인터페이스를 통해 애플리케이션 기능을 제어할 수 있도록 런타임 구성을 지원하는 데 사용됩니다. 최종 결과는 Web Experience Factory를 사용하면 회사가 요구 시 변경(일반적인 도구 및 기술에서는 제공할 수 없는 작업)에 응답하는 적응 애플리케이션을 빠르게 작성할 수 있다는 것입니다.
새 프로젝트를 작성하거나 현재 프로젝트를 업그레이드한 후 웹 애플리케이션 또는 위젯이 사용되는지 확인하려면 몇 가지 단계를 더 완료해야 합니다.
새 모델을 작성하려면 을 클릭하십시오.
샘플 웹 애플리케이션 또는 위젯에 대해 작업하려면 프로젝트에 학습서 및 샘플 기능 세트를 포함시키고 프로젝트 탐색기를 사용하여 models/samples 폴더에서 파일 중 하나를 여십시오.
Web Experience Factory에서는 모델과 프로파일 편집 및 웹 애플리케이션 개발에 도움이 되는 다양한 사용자 인터페이스를 제공합니다.
Web Experience Factory Designer 실행 시 IBM Web Experience Factory 퍼스펙티브를 사용합니다. 이 퍼스펙티브에서는 모델 편집 및 웹 애플리케이션 구성을 지원하는 특별 메뉴 및 기타 기능을 제공합니다. 를 클릭하여 이 퍼스펙티브를 활성화하십시오. 창 제목에 Web Experience Factory 퍼스펙티브가 사용 중임이 표시됩니다. 퍼스펙티브는 Eclipse 및 Web Experience Factory 보기, 모델 편집기 및 프로파일 편집기 둘 모두를 사용합니다.
이 보기에서는 다중 프로파일을 동일한 모델에 적용하는 경우 프로파일의 조합도 관리할 수 있습니다. 편집기 영역에 열기 모델이 선택된 경우에만 컨텐츠가 포함됩니다. 을 클릭하여 보기를 표시하십시오.
표준 Eclipse 특성 보기를 사용하여 모델의 필드에 대한 표시 및 유효성 검증 설정을 확인 및 표시할 수 있습니다. 을 클릭하면 이 보기가 표시됩니다.
을 클릭하여 보기를 표시하십시오. 보기에 표시되는 내용을 변경하려면 보기의 메뉴 표시줄에서 드롭 다운 목록을 사용하십시오.
프로젝트 탐색기는 표준 네비게이터의 확장된 버전입니다.
프로젝트 탐색기는 몇몇 기본 프로젝트 아티팩트(Java 소스, 모델 및 프로파일)에 대해 프로젝트 레벨 폴더 액세스를 제공합니다. 이러한 프로젝트 레벨 폴더를 사용하면 WEB-INF 디렉토리의 폴더에 있는 파일에 대해 작업할 수 있습니다. 폴더의 배치를 통해 디렉토리를 드릴다운하지 않고도 아티팩트에 액세스할 수 있습니다. 특수한 프로젝트 레벨 폴더 또는 해당 자원이 실제로 이 프로젝트 파일 구조에 있는 WEB-INF 아래의 폴더에서 탐색하여 해당 폴더의 파일에 대해 작업할 수 있습니다.
프로젝트 탐색기 보기는 현재 프로젝트를 구성하는 모든 오브젝트를 표시하는 트리 기반의 디렉토리 계층 구조를 표시합니다. 프로젝트 탐색기는 IBM Web Experience Factory 프로젝트의 전체 트리를 표시할 수 있습니다. 프로젝트 구성 요소의 서브세트를 지정하여 해당 트리에 표시하고 트리에서 선택한 요소에서 리팩토링을 수행할 수 있습니다. 오브젝트(예: 모델 또는 프로파일 세트)를 탐색하여 두 번 클릭하면 해당 오브젝트를 열 수 있습니다. 오브젝트는 적당한 편집기에 표시됩니다.
모델 네비게이터 보기에 프로젝트 탐색기의 서브세트가 표시되어 프로젝트에 정의된 모델 및 프로파일 세트에 더 수월하게 액세스할 수 있습니다. 를 클릭하여 보기를 표시하십시오.
두 보기 모두에서 계층 구조를 펼치고 표시를 필터링할 수 있습니다.
모델 또는 프로파일 세트의 이름을 바꾸려면 명령을 사용하십시오.
프로젝트 탐색기는 Eclipse 및 Rational Application Developer에서 지원됩니다. 이전 버전의 Eclipse 및 Rational Application Developer의 모델, 프로파일 및 Java 소스에 대해 링크 폴더가 제공되므로 사용자가 표준 네비게이터에서 해당 자원을 신속하게 찾아 이동할 수 있습니다.
필요하지 않은 유형을 필터링하여 프로젝트 탐색기에 표시되는 요소 유형을 제어할 수 있습니다.
프로젝트
탐색기 트리에 표시되는 자원 목록을 제한하거나 확장하려면
프로젝트 탐색기 탐색줄에서 메뉴 아이콘(
)을 클릭한 후
필터를 클릭하고 사용 가능한 필터
옵션에서 선택란을 선택하거나 선택 취소하십시오.
필터를 선택하면
해당 필터 유형의 가시성이 꺼집니다. 예를 들어, 프로젝트가 사용하는 모델만 표시하려면
비모델을 선택하여 모델이 아닌 모든 자원의
가시성을 끄십시오.
또한 표시할 자원 인벤토리를 제한하려면 필터 대화 상자의 사용 가능한 컨텐츠를 클릭하고 프로젝트 탐색기에서 표시할 자원을 선택한 다음 표시하지 않을 자원을 지우십시오.
프로젝트 탐색기는 기본으로 표시됩니다.
프로젝트 탐색기를 닫은 경우 를 클릭한 후 를 선택하여 다시 표시할 수 있습니다.
프로젝트 탐색기에서 자원을 열 경우, 자원에 대한 정보는 별도 분할창의 현집기에서 나타납니다. 자원을 마우스 오른쪽 단추로 클릭하고 나타나는 팝업에서 열기를 클릭하여 항목을 엽니다. 예를 들어, 모델을 열면 모델 편집기가 나타납니다. 여기에는 다음 탭이 포함되어 있습니다.
프로파일 세트를 열면 탭 세트 및 단추 세트가 있는 프로파일 편집기가 나타납니다. 이 편집기를 사용하여 세트에서 프로파일을 추가, 편집 또는 삭제할 수 있습니다. 개별 프로파일을 열려면 프로파일 세트를 열고 아웃라인에 해당 컨텐츠를 표시해야 합니다.
편집기에서 빌더 호출 이름을 바꿀 수 있습니다.
IBM Web Experience Factory에서 프로파일 편집기를 사용하면 프로파일 세트를 작성 및 관리할 수 있습니다.
Web Experience
Factory 의 편집기 영역 맨 위에 있는
프로파일 세트 아이콘(
)이 포함된 탭을 통해 편집용으로 열린
프로젝트 프로파일 세트에 액세스할 수 있습니다. 초점을 포함한 이 탭은 X를 표시하여
모든 보기의 컨텐츠를 채웁니다.
IBM Web Experience Factory 퍼스펙티브의 아웃라인 보기는 편집 영역에서 선택한 모델에 대한 빌더 호출 목록을 표시합니다.
현재 선택한 모델에 대한 빌더 호출 목록은 모델에 있는 각 빌더 호출의 번호, 이름 또는 유형에 따라 나열됩니다. 프로파일링된 빌더 호출은 프로파일 아이콘을 표시합니다. 보기 도구 모음의 아이콘을 사용하면 현재 모델을 즉시 생성하거나 모델에 빌더 호출을 추가할 수 있습니다.
아웃라인 보기는 빌더 호출을 선택하고 사용할 수 있는 명령(예: 잘라내기, 복사 및 붙여넣기)을 사용하여 목록의 빌더 호출을 관리할 수 있는 팝업 메뉴를 지원합니다.
빌더 호출 목록에서 빌더 호출을 끌어서 놓아 다시 정렬할 수 있습니다. 빌더 호출 목록의 숫자 부호(#)는 빌더 호출의 번호순을 표시합니다. 하나의 빌더 호출이 목록에서 다른 빌더 호출에 종속된 경우, 호출에 실패하므로 목록의 빌더 호출 순서는 중요합니다. 사용하지 않는 빌더 호출은 회색으로 표시됩니다.
빌더의 이름 입력으로 입력할 수 있는 지정이 이름에 있습니다. 이름을 입력하지 않은 경우 페이지 위치를 기초로 생성됩니다. 그렇지 않으면 <No Name>으로 표시됩니다. 빌더 선택도구에서 선택된 대로 실제 빌더의 지정이 유형에 있습니다. 다른 열에서는 빌더 호출에 연관 프로파일이 포함되었는지 여부를 표시합니다.
보기 메뉴 끝에 있는 이름 목록은 사용자 모델에 추가할 수 있는 빌더를 제안합니다. 빌더 이름을 클릭하면 모델에 빌더가 추가되고 편집기 영역에서 빌더 호출 편집기가 열립니다.
정렬 기준 명령을 사용하면 여러 방식으로 목록 표시를 배치합니다. 기본값은 번호순입니다. 또한 열 제목을 클릭하여 빌더 호출 목록을 정렬할 수 있습니다.
명령은 기준 및 문자열과 일치하는 입력이 있는 빌더를 찾아 빌더 호출 목록에 해당 호출만 표시합니다. 완료 후 전체 빌더 호출 목록을 복원하려면 다음으로 시작 및 빈 문자열을 지정하고 확인을 클릭하십시오.
열에는 각 나열된 빌더 호출의 화살표 아이콘이 포함됩니다. 이를 통해 다른 보기의 관련된 요소에 연결됩니다. 이 화살표를 클릭하여 애플리케이션 트리 및 페이지 보기의 관련된 요소를 강조 표시하십시오. 또한 이 기능으로 소스 보기의 코드 및 설계 보기의 관련 오브젝트를 표시하고 강조 표시합니다. 보기 풀다운 메뉴에서 애플리케이션 트리 연결을 설정하는 경우 목록에서 다른 빌더 호출을 선택할 때마다 애플리케이션 트리 보기, 페이지 보기, 소스 보기 및 설계 보기 강조 표시가 변경됩니다. 명령 세트를 사용하면 화살표 아이콘이 열에 표시되지 않습니다. 명령은 IBM Web Experience Factory Designer에 성능 오버헤드를 추가하므로 기본적으로 설정되지 않습니다.
보기 메뉴의 열 명령을 사용하여 빌더 호출 목록에서 열 순서 및 모양을 제어할 수 있습니다.
빌더 호출은 모델을 정의하는 모든 빌더 호출을 포함합니다.
빌더 호출 목록은 모델이 편집할 수 있도록 열리면 개발 환경의 아웃라인 보기에 렌더링됩니다. 빌더 호출 목록은 순서 번호, 이름 및 모델에 있는 각 빌더 호출의 유형을 표시하고, 빌더 호출이 프로파일링되는지 여부를 나타냅니다.
빌더 호출 목록을 사용하여 빌더 호출을 정렬, 필터링 및 범주화할 수 있습니다. 빌더 호출을 선택하고 컨텍스트(마우스 오른쪽 단추 클릭) 메뉴에서 사용할 수 있는 명령(잘라내기, 복사, 사용 가능 등)을 사용하여 목록의 빌더 호출을 관리할 수 있습니다.
사용하지 않는 빌더 호출은 회색으로 표시됩니다.
IBM Web Experience Factory는 이러한 빌더 호출을 빌더 호출 목록에 나타나는 숫자순으로 실행합니다. 각 빌더 호출이 실행될 때 웹 애플리케이션 오브젝트에 요소를 추가하거나 웹 애플리케이션 오브젝트의 요소를 수정합니다.
모델에서 웹 애플리케이션을 생성할 때 Web Experience Factory는 빌더 호출 입력에 사용한 모든 간접 참조를 분석하고 프로파일된 빌더 호출 입력에 해당 프로파일의 값을 제공합니다.
빌더 호출의 선형 실행 결과로서, 사용자가 목록에 빌더 호출을 배치하는 순서가 중요합니다. 예를 들어, 빌더 호출 입력의 메소드가 리턴하는 값을 참조하려면 현재 빌더 호출 전에 해당 메소드를 웹 애플리케이션에 추가하십시오.
모델을 개발할 때, 필요한 오브젝트에 액세스할 수 없는 빌더 호출을 추가할 수 있습니다. 예를 들어, 데이터 필드 수정자 빌더 호출이 조작하는 요소가 포함된 데이터 페이지 빌더 호출 앞에 이 데이터 필드 수정자 빌더 호출을 추가하거나 이동하는 경우 Web Experience Factory Designer가 다음과 비슷한 경고를 표시합니다.
Field selector "[page1]ShowEmployeeData/RowSet/Row/EMPNO" did not evaluate to any fields.
Ensure that this BuilderCall follows the corresponding Data Page BuilderCall.
이 경우, 데이터 필드 수정자 빌더 호출을 데이터 페이지 빌더 호출 아래로 끌면 오류가 제거됩니다.
일반적으로, 빌더 호출 목록에 빌더 호출을 추가할 때 한 호출이 다른 호출에 대해 갖는 종속성을 알아 두십시오. 아직 작성될 호출(또는 호출 아티팩트)에 종속된 목록에 호출을 배치하지 않도록 하십시오. 하향식으로 빌더 호출 목록을 채우고 목록에 추가하는 호출이 그 위의 빌더 호출에만 종속되는지 확인하십시오.
다음 빌더 호출 목록 보기 옵션을 사용하여 모델에서 빌더 호출 표시를 변경할 수 있습니다.
빌더 선택도구는 사용자 환경에서 사용할 수 있는 빌더를 나열하고 모델에 추가할 수 있는 빌더를 선택하는 방법을 제공합니다. 이 보기를 펼치거나 축소하려면 적게 표시 및 자세히 표시를 사용하십시오.
이 분할창은 빌더를 관리하고 관련 빌더를 찾은 데 도움이 되는 폴더를 제공합니다. 제공되는 모든 빌더는 하나 이상의 카테고리에 지정되어 빌더 선택도구의 해당 카테고리에 따라 빌더를 볼 수 있습니다. 일부 빌더는 여러 카테고리로 표시됩니다. 카테고리는 빌더를 구성하는 방법을 제공합니다. 예를 들어, 카테고리 이름 아래에 있는 페이지 요소를 클릭하면 작성 중이며 조작 중인 페이지를 포함하고 있는 모든 빌더가 표시됩니다.
즐겨찾기 관리를 사용하여 목록에서 항목을 제거하십시오.
예를 들어, 빌더 분할창의 상위에 있는 검색 상자에 문자 p를 입력한 경우 스크롤 가능한 드롭 다운 목록에 p를 포함하고 있는 모든 키워드가 표시됩니다. 키워드 page를 포함한 경우 page를 포함하고 있는 모든 키워드가 표시됩니다.
키워드를 클릭하여 텍스트 상자에 표시되고 검색 결과에 저장되도록 하십시오. 해당 키워드와 연관된 빌더의 이름은 빌더 아래에 표시되어 있습니다. 드롭 다운 목록에서 마지막 항목인 모든 빌더 키워드 포함 및 검색 용어를 클릭하여 키워드를 검색 결과에 추가하고 빌더 아래에 연관된 빌더 이름을 나열하십시오.
검색 결과를 펼쳐서 저장된 키워드를 나열하십시오. 키워드를 클릭하여 해당 키워드와 연관된 빌더의 이름으로 빌더의 목록을 제한하십시오.
빌더 선택도구 대화 상자가 닫히면 검색 결과가 지워집니다.
이 분할창은 카테고리 이름의 선택사항을 기준으로 또는 검색 상자에 입력한 키워드로, 빌더 이름을 알파벨 순서로 나열합니다. 이름을 선택한 후 확인을 클릭하여 빌더를 모델에 추가하십시오.
기본적으로 이 패널은 선택한 빌더에 대한 정보를 표시하여 빌더를 추가할지 여부를 결정할 수 있습니다. 이 패널은 빌더에 대해 자세한 정보가 들어 있는 링크를 제공합니다.
기본적으로 도움말이 표시되지 않도록 선택한 경우 도움말을 다시 표시하려면 F1을 누르거나 물음표 아이콘을 클릭하십시오.
빌더 선택도구를 사용하여 Web Experience Factory 설치에 포함되거나 추가된 빌더를 추가할 수 있습니다.
빌더를 선택한 후 확인을 클릭하면 빌더 선택도구가 이 빌더에 대한 빌더 호출 편집기를 닫고 실행합니다.
IBM Web Experience Factory Designer에 사용 가능한 빌더 목록을 업데이트할 수 있습니다.
빌더 선택도구의 빌더 목록에 다른 빌더가 포함되도록 업데이트할 수 있습니다. WEB-INF/builders 디렉토리에 추가된 빌더 정의에 의해 정의된 빌더가 빌더 정의에 정의된 기타 카테고리 및 모든 카테고리에 나열됩니다. 빌더 목록에서 빌더 이름이 표시되지 않은 이유는 다음과 같습니다.
프로젝트를 수정하고 기능 세트를 추가할 수 있습니다. 빌더는 빌더 선택도구에 나열됩니다.
프로젝트 버전을 업그레이드하여 빌더 목록을 업데이트해야 합니다.
빌더 목록을 업데이트할 수 있습니다.
빌더 호출 편집기를 열지 않고 빌더의 기본 도움말 항목을 열 수 있습니다.
빌더 선택도구 대화 상자에서 즐겨찾기 관리를 클릭하여 자주 사용하는 빌더 목록을 유지보수할 수 있습니다.
이 목록은 빌더 선택도구에 있는 카테고리 이름의 즐겨찾기 폴더에 저장됩니다.
질문 표시 아이콘을 클릭하여 대화 상자에 대한 도움말 트레이 컨텍스트 정보에 표시하십시오.
아웃라인 보기에서 마우스 오른쪽 단추로 클릭하면 빌더 호출 목록을 관리하고 빌더 호출에 대한 다른 조작을 수행하는 데 사용할 팝업 메뉴가 열립니다.
이 메뉴의 일부 옵션은 빌더 호출을 선택한 경우에만 사용할 수 있습니다. 이 메뉴는 다음 명령과 조치에 대한 액세스를 제공합니다.
이 메뉴는 빌더를 거의 동등한 입력이 있는 유사한 유형의 빌더로 변환할 경우 유용합니다. 예를 들어, 단추 빌더를 링크 빌더로 변환하거나 페이지 빌더를 가져온 페이지 빌더로 변환하는 경우가 해당됩니다.
일반적으로, 빌더 변환은 동일한 카테고리의 빌더를 포함해야 합니다. 예를 들어, 페이지 카테고리 또는 페이지 요소 카테고리 내의 한 빌더 유형에서 다른 빌더 유형으로 변환하십시오. 속성 또는 설계면에서 근본적으로 다른 빌더를 변환하려고 시도하지 마십시오.
원래 빌더 입력은 보존되며, 해당되는 경우 새 빌더에 지능적으로 적용됩니다. 예를 들어, 단추 레이블 입력 값이 링크 텍스트 입력에 적용됩니다. 원래 빌더의 모든 입력이 새 빌더 호출 편집기에 추가됩니다.
IBM Web Experience Factory는 Web Experience Factory 퍼스펙티브 편집기 영역의 몇 가지 패널을 사용하여 웹 애플리케이션의 모델을 작성하고 개발합니다.
프로젝트 탐색기 또는 모델 네비게이터 보기를 사용하여 모델 편집기에서
모델에 액세스하고 여십시오. Web Experience
Factory 퍼스펙티브의
편집기 영역 맨 위에 있는 모델 아이콘(
)이 포함된 탭을 통해 편집용으로 열린
프로젝트 모델에 액세스할 수 있습니다. 초점을 포함한 이 탭은 X를 표시하여
모든 보기의 컨텐츠를 채웁니다.
탭이 별표(*)를 표시하면, 모델에 변경사항이 저장되지 않습니다.
모델 편집기에서 패널을 사용하여 모델에서 빌더 호출의 효과를 이해하거나 빌더 호출을 변경하거나 모델에 있는 요소 사이의 관계를 검사할 수 있습니다. 패널은 다음과 같습니다.
웹 애플리케이션 트리는 모델이 재생성될 때마다 업데이트됩니다.
애플리케이션 트리는 편집기 영역에서 선택된 열기 모델의 생성 요소를 나열합니다.
모델 편집기의 애플리케이션 트리를 사용하여 생성 요소를 탐색하고 액세스할 수 있습니다. 모델 편집기에서 초점을 포함하는 열기 모델을 사용하여 애플리케이션 트리 탭을 클릭하여 패널을 노출하고 생성 요소가 유형별로 나열된 하위 폴더 및 웹 애플리케이션 폴더를 볼 수 있습니다. 애플리케이션 트리 탭이 표시되지 않는 경우 편집기 영역의 왼쪽에 있는 화살표 아이콘을 클릭하여 선택된 패널을 축소하고 애플리케이션 트리 패널을 노출하십시오.
모델의 생성 요소는 웹 애플리케이션 폴더에서 트리 양식으로 표시됩니다. 요소 유형을 표시하는 폴더는 펼치거나 접을 수 있습니다. 예를 들어 웹 애플리케이션의 모든 변수는 변수 폴더에 포함됩니다. 기타 요소 유형에 대해서도 동일하게 해당됩니다. 이와 같이 생성된 요소가 구성되어 있어서 웹 애플리케이션의 컨텐츠 및 재생성 중 웹 애플리케이션 변경 방법을 시각적으로 쉽게 표시할 수 있습니다. 예를 들어, 애플리케이션 트리를 사용하여 빌더가 웹 애플리케이션에 추가하는 항목을 결정할 수 있습니다.
상대 페이지 탭을 클릭하여 페이지 및 양식 요소에 더 빨리 액세스할 수 있습니다.
애플리케이션 트리에서 선택된 생성 요소의 각 유형마다 해당 코드가 소스 패널에 표시됩니다.
소스 패널을 사용하여 메소드 또는 빌더 호출에서 생성된 관련 코드를 검사하십시오.
애플리케이션 트리에서 폴더를 펼친 후 웹 애플리케이션 오브젝트를 클릭하면 오브젝트를 작성해야 하는 빌더가 빌더 호출 목록에서 강조 표시됩니다. 마찬가지로 아웃라인 보기의 빌더 호출을 선택하고 웹 애플리케이션 트리와 연결을 사용 가능하게 설정하는 경우 해당 빌더 호출과 연관된 생성 요소가 애플리케이션 트리에서 선택됩니다.
애플리케이션 트리 조작은 소스 보기 및 설계 보기와 밀접하게 연관되어 있습니다.
애플리케이션 트리 맨 위에는 표준 Eclipse 트리 필터가 있습니다. 필터에 텍스트를 입력하면 증분 검색이 수행됩니다. 이름 시작 부분에 필터 문자가 있는 자원만 WebApp 폴더의 관련 하위 폴더에 표시됩니다. 별표 문자(*)를 입력한 다음 텍스트를 입력하면 이름의 임의 위치에 해당 텍스트가 있는 자원이 표시됩니다. 아이콘을 사용하여 필터를 지우거나 모든 자원을 표시할 수 있습니다.
애플리케이션 트리에서 지원되는 팝업 메뉴에서 작성 빌더를 더 빨리 열거나 선택된 요소를 수정할 수 있습니다.
일반적으로 애플리케이션 트리에 표시되는 폴더는 다음과 같습니다.
Event: OnError.mainAction: showErrorPage
모델의 양식 및 페이지에 추가로 직접 액세스하려면 페이지 패널을 사용하십시오.
모델을 시각적으로 표시할 수 있습니다.
설계 보기를 클릭하고 비표시 항목이 애플리케이션 트리에 선택되거나 표시될 수 없는 요소가 모델에 있는 경우 다음 텍스트가 표시됩니다.
모델에 페이지 요소를 작성하는 빌더를 추가했는지 확인하십시오.
모델 편집기의 설계 및 관련 페이지 패널은 빌더의 시각적 요소에 대한 그래픽 표시를 제공합니다.
설계 패널에서는 페이지의 필드 및 필드 그룹을 변경할 수 있습니다.
페이지 패널에는 모델의 모든 작성 페이지 및 양식에 대한 섬네일 아이콘이 표시됩니다. (동일한 생성 요소가 애플리케이션 트리에 나열됩니다.) 페이지 탭을 클릭하여 분할창을 노출하십시오. 아이콘으로 모델의 시각적 요소를 더 수월하게 선택할 수 있습니다. 페이지 도구 모음의 보기 아이콘으로도 표시 요소의 목록 및 세부사항 형식을 표시할 수 있습니다.
페이지 패널에 지원되는 팝업 메뉴에서 작성 빌더를 더 빨리 열거나 선택된 요소를 수정할 수 있습니다.
설계 패널은 애플리케이션 트리 또는 페이지 패널의 선택된 표시 요소를 시각적으로 표시합니다. 설계 탭을 클릭하면 설계 패널이 노출됩니다. 이 패널에서는 웹 애플리케이션을 생성하지 않아도 모델의 표시 요소를 빠르고 편리하게 확인할 수 있으며, 설계를 변경할 수 있습니다.
분할창에서 태그는 페이지의 상자를 통해 시각적으로 표시됩니다. 태그는 빌더를 추가할 위치를 표시하기 위해 표시됩니다. 태그 이름은 상자로 표시됩니다.
편집기 패널의 왼쪽에 있는 화살표 아이콘을 토글하여 애플리케이션 트리 및 페이지 패널을 숨기거나 노출할 수 있습니다. 다른 패널을 숨기면 빌더 호출 편집기로 작업할 화면 공간이 더 많이 확보됩니다. 시각적 표시에는 빨간색 별표 및 텍스트 표시기가 포함됩니다. 이는 연관된 요소에 빌더 호출 편집기로 제거해야 할 오류 조건이 포함되어 있음을 표시합니다. 또한 그룹 아이콘이 포함되어 사용자가 총계 요소에서 쉽게 조작할 수 있습니다.
설계 패널은 애플리케이션 트리와 확고히 연결됩니다. 설계 패널의 요소를 선택하는 경우 애플리케이션 트리의 해당 요소가 선택됩니다. 또한 소스 패널의 연관 코드가 강조 표시됩니다.
설계 패널에 지원되는 팝업 메뉴 옵션 및 팔레트를 통해 웹 애플리케이션을 개발할 수 있습니다. 사용 가능한 팝업 메뉴 옵션은 패널에서 선택된 요소의 컨텍스트에 따라 다릅니다. 분할창의 요소 또는 그룹 아이콘을 마우스 오른쪽 단추로 클릭하면 메뉴가 표시됩니다.
설계 패널의 모델에 추가하는 빌더의 빌더 호출 편집기에서 선택된 요소의 컨텍스트에 기반하여 페이지 및 태그 필드가 사전에 입력됩니다.
한 데이터를 여러 필드에 사용해야 하는 경우가 있습니다. 그러나 이 데이터를 표시할 때 이러한 여러 필드가 하나의 열로 표시되도록 하고자 할 수 있습니다. 예를 들어, 어떤 사람의 주소가 시/도, 구/군/시, 우편번호 필드로 구성되어 있을 수 있습니다. 이 경우 데이터 필드 병합 빌더를 사용하여 개별 필드를 세부사항 페이지의 단일 필드 또는 단일 표시 열로 처리할 수 있습니다.
설계 패널에서 병합할 여러 개의 필드를 선택한 다음 필드 병합을 클릭하면 필드가 현재 열로 병합됩니다. 여러 필드는 모두 같은 컨테이너 필드에 있어야 합니다. 메뉴 명령과 관련된 정보를 채우면 데이터 필드 병합 빌더가 모델에 추가되고 새로 병합된 열이 표시됩니다.
설계 패널에서 페이지 자동화 필드를 마우스 오른쪽 단추로 클릭한 다음 또는 을 클릭하십시오. (유효성 검증 명령은 데이터 입력 필드에 대한 메뉴에서만 사용할 수 있습니다.) 설정을 변경하고 적용 또는 확인을 클릭하십시오.
양식이나 페이지에서 열 또는 필드를 마우스 오른쪽 단추로 클릭하면 또는 를 사용하여 빠르게 표시 설정을 변경할 수 있습니다. 명령을 사용하여 필드 또는 열이 표시되지 않도록 하거나 표시되도록 하는 특성을 토글할 수 있습니다.
양식이나 페이지에서 열 또는 필드를 마우스 오른쪽 단추로 클릭하면 또는 를 사용하여 빠르게 정렬 설정을 변경할 수 있습니다. 명령을 사용하여 필드 또는 열이 정렬되도록 하거나 정렬되지 않도록 하는 특성을 토글할 수 있습니다.
모델에 이 양식이나 페이지에 대한 관련 빌더가 없는 경우 권장 빌더가 모델에 추가됩니다. 이 양식이나 페이지에 대한 관련 빌더가 모델에 있는 경우 해당 빌더의 관련 입력이 변경사항으로 업데이트됩니다.
모델 편집기의 소스 패널에는 애플리케이션 트리, 설계나 페이지 패널의 선택된 생성 요소 또는 아웃라인 보기의 선택된 빌더 호출과 연관된 애플리케이션 코드가 표시됩니다.
소스 탭을 클릭하여 분할창을 노출하십시오. 편집기 영역의 왼쪽에 있는 화살표 아이콘을 사용하여 패널을 펼치거나 축소하십시오. 예를 들어 애플리케이션 트리 및 페이지 탭이 표시되지 않는 경우 화살표를 클릭하여 소스 패널을 축소하고 다른 패널을 노출하십시오.
애플리케이션 트리에서 생성 요소를 탐색하고 선택하십시오. 페이지 패널에서 페이지 또는 양식을 선택하십시오. 설계 패널에서 표시 요소를 선택하십시오. 소스 패널의 관련된 소스 코드가 강조 표시됩니다.
아웃라인 보기의 웹 애플리케이션 트리와 연결을 사용 가능하게 설정하는 경우 빌더 호출을 선택하면 애플리케이션 트리의 연관된 요소가 선택되고 소스 패널의 관련된 소스 코드가 강조 표시됩니다.
소스 패널에 코드 정보 및 코드 자체가 둘 다 표시됩니다. 요소에 대한 정보를 접거나 펼치려면 요소 이름 왼쪽의 삼각형 아이콘을 사용하십시오. 정보를 접으면 소스 코드 표시에 필요한 공간이 더 많이 확보됩니다.
현재 선택을 호출한 메소드
선택된 코드가 호출하는 메소드
코드에 대한 정보를 사용하여 모델의 조작을 더 빨리 이해할 수 있습니다.
소스 보기 및 설계 보기 탭에는 애플리케이션 트리에서 선택하는 요소의 세부사항이 표시됩니다.
소스 보기 탭을 선택하고 애플리케이션 트리 보기의 선택된 오브젝트에 사용 가능한 소스가 없는 경우 다음 주제를 참조합니다. 해당 모델의 빌더에서 작성된 요소의 소스 코드를 소스 보기에 표시하는 데 사용할 수 있습니다.
모델 편집기(애플리케이션 트리, 페이지 패널 및 설계 패널)의 팝업 메뉴에는 선택된 생성 요소를 수정할 수 있는 사용 가능한 빌더 및 선택된 오브젝트를 작성한 빌더 모두가 현재 컨텍스트로 표시됩니다.
이 메뉴는 빌더를 거의 동등한 입력이 있는 유사한 유형의 빌더로 변환할 경우 유용합니다. 예를 들어, 단추 빌더를 링크 빌더로 변환하거나 페이지 빌더를 가져온 페이지 빌더로 변환하는 경우가 해당됩니다.
일반적으로, 빌더 변환은 동일한 카테고리의 빌더를 포함해야 합니다. 예를 들어, 페이지 카테고리 또는 페이지 요소 카테고리 내의 한 빌더 유형에서 다른 빌더 유형으로 변환하십시오. 속성 또는 설계면에서 근본적으로 다른 빌더를 변환하려고 시도하지 마십시오.
원래 빌더 입력은 보존되며, 해당되는 경우 새 빌더에 지능적으로 적용됩니다. 예를 들어, 단추 레이블 입력 값이 링크 텍스트 입력에 적용됩니다. 원래 빌더의 모든 입력이 새 빌더 호출 편집기에 추가됩니다.
선택된 생성 요소에 대한 HTML 코드가 포함된 파일을 작성합니다.
전체 페이지에 대한 HTML 코드가 포함된 파일을 작성합니다.
페이지 자동화에서 생성하는 페이지(예: 데이터 서비스 사용자 인터페이스 빌더에서 작성하는 페이지)에만 이들 명령을 사용할 수 있습니다.
카테고리의 하위 메뉴에서 빌더 이름을 클릭하여 요소를 수정하는 새 빌더 호출을 모델에서 작성할 빌더 호출 편집기를 실행하십시오.
빌더의 목록 및 카테고리는 철저하지 않습니다. 일부 빌더는 특정 요소를 작성할 수 있지만 해당 컨텍스트에 적합하지 않으므로 목록에 없습니다.
설계 패널에서 페이지 자동화 필드를 마우스 오른쪽 단추로 클릭한 다음 또는 을 클릭하십시오. (유효성 검증 명령은 데이터 입력 필드에 대한 메뉴에서만 사용할 수 있습니다.) 설정을 변경하고 적용 또는 확인을 클릭하십시오.
모델에 이 양식이나 페이지에 대한 관련 빌더가 없는 경우 권장 빌더가 모델에 추가됩니다. 이 양식이나 페이지에 대한 관련 빌더가 모델에 있는 경우 해당 빌더의 관련 입력이 변경사항으로 업데이트됩니다.
Ctrl 키 및 클릭을 사용하여 명령에 대해 동일한 유형(필드 또는 열)의 여러 오브젝트를 선택하십시오.
설계 패널에서 병합할 여러 개의 필드를 선택한 다음 필드 병합을 클릭하면 필드가 현재 열로 병합됩니다. 여러 필드는 모두 같은 컨테이너 필드에 있어야 합니다. 메뉴 명령과 관련된 정보를 채우면 데이터 필드 병합 빌더가 모델에 추가되고 새로 병합된 열이 표시됩니다.
모델 편집기의 모델 XML 패널은 모델의 XML을 디스크에 저장된 대로 표시합니다.
빌더를 작성하는 경우 모델 XML 패널을 사용하여 간접 참조를 해석하는 방법을 점검할 수 있습니다. 또한 다양한 빌더(예: 데이터 페이지 빌더 및 데이터베이스 빌더)에서 생성된 스키마를 점검할 수 있습니다.
빌더 호출 편집기를 사용하여 빌더 호출에 대한 입력 값을 모두 지정할 수 있습니다.
또한 XML 구조의 요소를 참조하고 모델의 하나 이상의 페이지에 제어 빌더 호출을 위치시킬 수도 있습니다.
다음 빌더 호출 입력 그룹은 다수의 빌더에 공통적입니다.
TODO Update the style for this page
FIXME Add SmartPhone support
API를 통해 빌더를 호출할 때 태스크가 빌더에 추가될 수도 있습니다. 빌더가 대상 빌더를 호출하는 경우 호출하는 빌더는 심각도 표시기 태스크와 함께 메시지를 호출에 추가합니다. 표시된 메시지는 대상 빌더에 추가됩니다.
메시지에는 빌더가 원하는 어떤 텍스트도 있을 수 있지만, 표준 TODO 및 FIXME 동작을 원하는 경우에는 메시지를 TODO 또는 FIXME로 시작해야 합니다. 이러한 태스크는 빌더가 더 이상 이러한 메시지를 생성하지 않게 될 때까지 표시됩니다. 그러면 빌더가 사용자에게 고급 기능을 지원하기 위해 태스크를 동적으로 추가할 수 있습니다.
빌더에 따라 기타 옵션이 있을 수 있습니다.
빌더 호출에 대한 대부분의 입력은 간접 참조, Java 표현식에서 파생된 값을 취하거나 문자열 값에서 직접 값을 취할 수 있습니다. 변수 또는 모델과 같은 특정 오브젝트에 대한 이름이 필요한 일부 입력은 적절하지 못한 요소를 필터하는 특정 선택기를 사용합니다.
일반적으로, Java 변수와 동일한 규칙을 사용하여 모델의 빌더 이름을 지정하십시오.
(처음 소문자, 그 다음에 각 단어의 첫 번째 문자에 대문자 사용.) 예:
종종 처음 소문자 규칙을 따르지 않아야 합니다. 예를 들어, 포틀릿 어댑터 빌더의 이름 입력은 생성된 웹 애플리케이션 오브젝트에 대해서가 아니라 포털의 포틀릿 이름으로 사용되므로 이 빌더 호출 이름에 처음 대문자를 사용하는 것이 합당합니다.
제어 빌더(단추 또는 링크 빌더와 같은)에 대한 이름 입력은 일반적으로 공백으로 남겨 둡니다. 이 입력이 공백이면 제어 빌더가 위치한 태그 이름을 자동으로 표시합니다.
참조 선택 대화 상자를 사용하여 모델 엔티티 값을 빌더 입력 값으로 지정할 수 있습니다.
참조 선택 대화 상자는 선택된 요소의 출력 값을 빌더 호출에 대한 입력 값에 맵핑하기 위해 선택할 수 있는 변수, 메소드, 입력 및 페이지를 모두 표시합니다. 스키마와 연관된 XML 구조에 대한 참조의 경우, 참조 선택 대화 상자에 모든 요소와 해당 요소와 연관된 모든 속성이 표시됩니다. 속성은 대화 상자 트리에서 이름 앞에 @ 기호로 구분됩니다.
참조 선택 대화 상자는 올바르지 않은 가능성을 걸러냅니다. 예를 들어, 단추 빌더의 레이블 입력 값이 메소드 출력 값, 변수 값 또는 이전에 제출된 페이지의 입력 값이 되도록 설정할 수 있습니다. 레이블 입력에 대한 참조 선택 대화 상자를 표시하면 페이지가 단추의 레이블을 파생하는 올바른 방법이 아니기 때문에 모델에 페이지가 표시되지 않습니다.
참조 선택 대화 상자는 인수를 갖지 않는 메소드만 표시합니다. 입력에 메소드가 리턴하는 값을 제공하려는 경우 일부 빌더가 참조 선택 대화 상자에서 선택된 메소드에 대한 인수를 지원하지 않음을 기억하십시오. 인수를 사용하는 메소드에서 리턴된 값으로 빌더 호출 입력을 제공하려면 메소드 호출 빌더 호출을 모델에 추가하여 메소드를 호출하고 그 곳에 인수를 제공하십시오. 참조 선택 대화 상자를 사용하고 방금 작성한 메소드 호출을 선택하여 입력 값을 설정하십시오.
다양한 방법으로 빌더 입력 값을 지정할 수 있습니다.
예를 들어, 입력 선택 상자 또는 텍스트 입력 제어를 사용할 수 있습니다. 이러한 제어를 사용하여 값을 지정하는 것이 간단합니다. 또한 IBM Web Experience Factory Designer는 사용자가 자원을 선택하도록 입력 값을 지정하기 위해 여러 유형의 선택기 제어를 사용합니다.
다음 대화 상자에는 사용자가 선택할 수 있는 요소가 표시됩니다. 예를 들어, 파일 선택 대화 상자에는 파일 또는 파일이 포함되어 있는 디렉토리 목록이 표시됩니다. 이 대화 상자를 사용하여 적절한 자원을 탐색하십시오.
간접 참조 유형의 조합을 사용할 수 있습니다.
예를 들어, Java 표현식과 변수 참조를 조합하여 이미지의 URL을 파생할 수 있습니다.
${Java/webAppAccess.getRequestData().getContextURL()}/${Variables/ImageFileName}
ImageFileName 변수에는 이미지의 파일 이름이 들어 있습니다.
빌더 입력을 위한 Java 구문을 입력할 수도 있습니다.
${Java/webAppAccess.getRequestData().getContextURL()}
인수를 사용하는 메소드가 리턴하는 값으로 텍스트 입력 값을 설정하려면 다음을 수행합니다.
${Java/webAppAccess.callMethod("MethodName", arg1, arg2)}
또한 참조 선택 대화 상자의 Java 노드는 사용할 수 있는 일부 사전 정의된 표현식을 제공합니다.
참조 선택 대화 상자에서 표현식을 선택하면 빌더 입력 필드에 배치됩니다. 인수를 추가하거나 수정하려는 경우 이때 표현식을 편집할 수 있습니다.
필요에 따라 간접 참조를 연결 또는 중첩할 수 있습니다.
${Variables/MyXML/XmlElement[${Variables/IndexValue}]}
중첩된 간접 참조를 작성하려면 다음을 수행하십시오.
을 클릭하여
참조 선택 대호 상자를 표시하십시오.참조 선택기를 사용하여 모델의 요소 값을 빌더 호출 입력에 지정할 수 있습니다.
참조 선택기는 값을 파생시킬 수 있는 변수, 메소드, 입력 및 페이지를 모두 표시합니다. 참조 선택기에서 항목을 선택할 때 참조 선택기가 리턴하는 값을 간접 참조라고 하며, 모델에서 선택된 요소 경로를 정의합니다(예: ${Variables/CustomerName} 또는 ${MethodCall/GetCustomerName}).
${Variables/Customers/Customer[${MethodCall/GetIndexValue}]}
참조 선택기는 선택된 요소의 출력 값을 빌더 호출에 대한 입력 값에 맵핑하기 위해 선택할 수 있는 모델 요소(예: 변수, 메소드, 입력 및 페이지)를 표시합니다. 기본적으로 참조 선택기는 유용할 것 같지 않은 여러 요소를 숨깁니다. 기본적으로 숨겨진 해당 요소를 표시하려면 대화 상자에서 자세히 표시를 클릭하십시오.
참조 선택기는 올바르지 않은 가능성을 필터합니다. 예를 들어, 단추 빌더의 레이블 입력 값이 메소드 출력 값, 변수 값 또는 이전에 제출된 페이지의 입력 값이 되도록 설정할 수 있습니다. 레이블 입력의 참조 선택기를 표시하면 모델의 페이지는 단추의 레이블을 파생하는 올바른 방법이 아니므로 해당 페이지가 표시되지 않습니다.
다음은 참조 선택기 사용의 측면입니다.
참조 선택기에서 간접 참조를 바로 입력하여 테마 특성 데이터에 대한 액세스를 제공할 수 있습니다.
${Properties/bowstreet.Theme/property-name}
이 참조는
사용자 인터페이스(UI) 요소를 정의하는 빌더 입력에 사용됩니다.
예를 들어, 페이징 단추 빌더에서 보통 단추 이미지 입력을
지정할 수 있습니다. 파일 경로를 지정하는 대신,
파일을 정의하는 테마 특성의 간접 참조를 사용할 수 있습니다.
이 방법에서는, UI 요소에 대한 참조의 정의를 중앙 집중화하므로
요소 변경이 필요한 경우 여러 빌더에서 여러 개의 입력을 수정하지 않아도 됩니다.<PagingButtons_NormalImage>/myfiles/images/normal.jpg
</PagingButtons_NormalImage>
이 정의는
WebContent 폴더에서 이미지 파일 경로를
지정합니다. 특성이 테마 파일에서 고유한지 확인하십시오. ${Properties/bowstreet.Theme/PagingButtons_NormalImage}
웹 애플리케이션이
구성될 때 모델 생성 시, normal.jpg 이미지는
해당 입력에 간접 참조가 있는 모든 페이지에 포함됩니다. 이 구문은 단일 값을 승인하는 빌더 입력에만 사용 가능합니다. 값 목록을 승인하는 입력에는 사용할 수 없습니다.
참조 선택기를 사용하여 페이지 제어 값을 지정하십시오(예: 단추의 레이블 또는 텍스트 입력).
요청 입력의 간접 참조를 선택하지 마십시오. 예를 들면, ${Inputs/someValue}입니다. 애플리케이션이 포틀릿 환경에서 실행되면 페이지의 다른 포틀릿에 대한 요청 결과로서 출력을 렌더링해야 할 수도 있습니다. 그러나, 요청 입력에서 값을 가져오는 모든 제어 또는 레이블에는 값이 없습니다.
이 애플리케이션의 우수 사례는 페이지 자동화 빌더(예: 데이터 필드 수정자 및 데이터 열 수정자 빌더가 있는 데이터 페이지 빌더)를 사용하는 것입니다. 또는, 변수에서 페이지 제어 값을 지정할 수 있습니다.
참조 선택기는 빌더 입력의 값을 제공할 수 있는 메소드를 보여줍니다.
인수가 필요한 메소드를 선택하면 팝업 대화 상자에 메소드의 인수를 입력하라는 메시지가 표시됩니다. 입력하는 메소드 인수는 하드코딩된 인수 또는 다른 메소드나 변수에 간접 참조가 되는 메소드 자체가 될 수 있습니다.
필요에 따라 간접 참조를 연결 또는 중첩할 수 있습니다.
예를 들어, 빌더 호출 입력 값으로 사용할 XML 요소 색인이 다른 변수에 의해 판별되는 경우 중첩된 간접 참조는 다음과 같습니다.
${Variables/MyXML/XmlElement[${Variables/IndexValue}]}
빌더 입력을 위한 Java 구문을 입력할 수 있습니다.
${Java/webAppAccess.getRequestData().getContextURL()}
두 개의 인수를 사용하는 MethodName 이름의 메소드 호출 방법:
${Java/webAppAccess.callMethod("MethodName", arg1, arg2)}
간접 참조 유형의 조합을 사용할 수 있습니다.
${Java/webAppAccess.getRequestData().getContextURL()}/${Variables/ImageFileName}
ImageFileName 변수에는 이미지의 파일 이름이 들어 있습니다.
쉼표로 분리된 목록을 승인하는 빌더 입력에 java.util.Collection을 구현하거나 java.util.Iterator를 확장하는 오브젝트를 제공하여, 빌더 입력 값을 기본 콜렉션의 항목으로 채울 수 있습니다.
${Java/webAppAccess.getRequestInputs().getInputValues("myInput")}
사용자가 작성한 표현식을 참조 선택 대화 상자의 Java 노드에 추가할 수 있습니다.
자주 사용되는 표현식을 대화 상자 내에서 계속 사용할 수 있도록 하기 위해 이 조작을 수행할 수 있습니다. 참조 선택 대화 상자를 표현식으로 채우려면 표현식을 정의하는 행을 ../WEB-INF/config/IndirectJavaExpressions.config 파일에 추가해야 합니다. 예를 들면 다음과 같습니다.
대화 상자에서 빌더 입력으로 모델을 지정할 수 있습니다.
여러 빌더의 모델 입력에서 사용자는 모델을 지정해야 합니다.
생략 기호 단추(
)를 클릭하면 모델을 탐색하고 선택할 수 있는
모델 선택기 대화 상자가 표시됩니다. 기본적으로 빌더에서 사용된 모델 위치의 스펙은
모델에 대한 절대 참조입니다.
모델 참조를 상대 참조가 되도록 하는 옵션(상대 모델 참조 사용)이 있습니다. 모델 A에서 모델 B로의 참조는 모델 폴더의 모델 A 위치에 기반합니다. 상대 참조를 사용하면 한 폴더에서 다른 폴더로 두 모델을 모두 이동하거나 복사하는 경우 모델 A의 새 사본이 모델 B의 새 사본을 참조합니다. 절대 참조를 사용하면 모델 A의 새 사본이 원래 위치에 있는 모델 B의 원본을 참조합니다.
빌더 호출 편집기는 가장 일반적으로 사용되는 참조 메소드 및 구문을 지원합니다.
웹 애플리케이션은 런타임 엔티티 세트(예: 변수, 메소드 및 서비스 호출)를 포함합니다. 상호간의 참조를 빌드하여 이 웹 애플리케이션 요소를 서로 연결합니다. 참조는 여러 가지 방법으로 작성할 수 있습니다. 그러나 적절한 입력 값을 제공하기 위해 간접 참조의 조합이 필요하고 XPath식 표기법을 사용하여 XML 요소에 대한 값을 가져와야 함을 알 수 있습니다.
대체 입력 양식을 사용하려면, 빌더 입력을 지정하는 올바른 구문을 알고 있어야 합니다. 다음 섹션의 정보는 사용 가능한 입력의 유형을 설명하고, 특정 입력 유형을 사용하기 위해 따라야 할 구문의 예제를 제공합니다.
모델에서 간접 데이터 참조를 사용할 수 있습니다. 예를 들어, 사용자가 입력하고 변수에 저장된 값을 변수에 대한 입력으로 사용할 수 있습니다. 변수에 대한 간접 데이터 참조를 사용하여 이 작업을 수행하십시오.
간접 참조의 구문은 다음과 같이 달러 부호 $ 다음에 중괄호 쌍이 와야 합니다.
${...}
중괄호는 데이터의 소스를 둘러싸고 있습니다. 다음 단추 레이블 예제에서, 다음 데이터 참조를 입력하여 단추 레이블 입력에 ButtonLabel 이름의 변수 값을 사용할 수 있습니다.
${Variables/ButtonLabel}
빌더 입력을 위한 Java 구문을 입력할 수 있습니다. IBM Web Experience Factory는 빌더 입력 값을 제공하기 위해 런타임 시 실행될 Java 표현식을 배치합니다. 웹 애플리케이션에서 선택기 또는 빌더 호출 편집기가 간접적으로 지원하는 요소를 지정할 경우 간접 참조에 대해 Java 표현식을 사용할 수 있습니다. 예를 들어, 입력에 Web Experience Factory의 URL을 제공하려면 다음 Java 표현식을 사용할 수 있습니다.
${Java/webAppAccess.getRequestData().getContextURL()}
다음 표현식은 인수를 사용하는 메소드가 리턴하는 값으로 텍스트 입력 값을 설정합니다.
${Java/webAppAccess.callMethod("MethodName", arg1, arg2)}
가져올 페이지의 값을 파생하려면 다음과 같은 유사한 간접 참조와 함께 간접 참조 유형의 조합을 사용할 수 있습니다.
${Java/webAppAccess.getRequestData().getContextURL()}/${Variables/PageToImport}
PageToImport 변수는 가져올 페이지의 이름을 포함합니다.
프로젝트를 찾고 작성하는 위치는 HTML 페이지, 생성된 JSP 페이지 및 기타 제공 가능 자원을 모두 포함하며, 제공 가능 컨텐츠 루트 디렉토리라고 부릅니다. 여러 애플리케이션 컨텍스트에 공개되거나 내보낼 수 있는 웹 애플리케이션을 개발할 때 webAppAccess.getRequestData().getContextURL() 메소드를 사용하여 제공 가능 자원에 대해 작성한 모든 참조가 모든 애플리케이션 컨텍스트를 허용할 수 있을 정도로 유연한지 확인해야 합니다. Java 표현식 사용을 참조하십시오. 제공 가능 자원 참조를 유연하게 작성하려면 메소드 또는 빌더 호출 입력에서 제공 가능 자원을 참조할 때 webAppAccess.getRequestData().getContextURL() 메소드를 사용하십시오. 예를 들어, 가져온 페이지 빌더의 가져올 페이지 입력에 대한 값으로 다음을 입력할 수 있습니다.
${Java/webAppAccess.getRequestData().getContextURL()}/pages_to_import_dir/MyPage.htm
이 구문은 항상 이 모델이 실행되는 애플리케이션 컨텍스트에 관계없이 pages_to_import_dir 디렉토리로 평가합니다.
메소드 호출의 결과로 얻은 데이터에 액세스하려면 간접 데이터 참조를 사용할 수 있습니다. 인수를 처리하지 않는 메소드 호출 또는 메소드를 사용할 수 있습니다. 그러나 이를 참조할 수 있도록 메소드는 값을 리턴해야 합니다. 또한 메소드 호출의 결과를 기타 메소드 호출 또는 문자열과 연결할 수도 있습니다. 이 간접 조치 유형에 대한 구문은 다음과 같습니다.
${MethodCall/methodName}
참조에 대한 메소드를 선택하려면 메소드 호출이라는 섹션이 포함되어 있는 트리를 표시하는 참조 선택기를 사용할 수 있습니다. 표시된 섹션은 사용될 수 있는 모델의 조치 목록, 메소드 및 메소드 호출을 나열합니다.
참고로 XML 변수를 사용할 수 있는 것과는 달리 메소드의 결과를 탐색할 수는 없습니다. 예:
${Variables/Customers/customer[2]/name}
추가 데이터 처리가 필요할 때나 이전에는 처리될 수 없었던 경우, 메소드 간접 데이터 참조 사용을 고려하십시오. 메소드 간접 참조 사용의 예는 반복 영역 빌더에 들어 있습니다. 일반적으로 모든 처리는 이 빌더의 실행 범위 내에서 수행하기 어렵습니다. 하지만 메소드에 대한 간접 참조를 사용하여 다음을 수행할 수 있습니다. 예를 들어, 테이블 행의 배경색을 대체해야 할 경우 메소드 호출을 사용할 수 있습니다. 언제든 각 색상을 리턴하는 getRowColor라는 메소드를 작성하십시오. 그런 다음 배경색을 설정하려면 테이블 행에 첨부하는 특성 세터 내에서 이 메소드에 대한 호출을 작성하십시오.
빌더 입력으로 텍스트의 문자열을 입력하려면 입력 영역에 직접 문자열을 입력할 수 있습니다. 또한 문자열을 채택하는 모든 입력에 대해서는 복수의 문자열을 연결할 수 있습니다. 예를 들어, 형식화된 텍스트 빌더에 대한 값 입력에 다음의 전체 행을 입력할 수 있습니다.
Foo 및 Bar의 값은 ${Variables/Foo} 및 ${Variables/Bar}입니다.
텍스트 빌더가 재생성되면 두 ${...} 영역이 참조되는 변수의 적절한 문자열 값으로 교체됩니다(값을 포함할 경우).
유사 기술을 사용하여 간접 조치를 중첩할 수도 있습니다. 결과로 텍스트 Foo 또는 텍스트 Bar를 포함하는 FooOrBar 이름의 변수가 있는 경우 다음과 같은 라인이 표시됩니다.
${Variables/FooOrBar}의 값은 "${Variables/${Variables/FooOrBar}}"입니다.
따옴표 파트는 Variables/FooOrBar의 값에 따라 Variables/Foo 또는 Variables/Bar에 저장된 문자열에 대해 평가합니다. 따라서 다음 값이 제공됩니다.
Variables/Foo: dataVariables/Bar: stuff
Variables/FooOrBar: Bar
위 행의 표현식의 결과는 다음과 같습니다.
Bar 값은 "stuff"입니다.
간접 참조 값의 연결에 설명된 유일한 참조 레벨은 데이터 액세스 및 조작에 대한 요구를 지원하지 않습니다. 간접 참조 메커니즘이 더 확장될 수 있습니다.
구문에 괄호 문자 [와 ]를 사용하여 목록에서 컴포넌트를 참조할 수 있습니다. XML 구조의 하위 요소 참조을 참조하십시오.간접 참조 메커니즘과 결합하여 이 구문을 사용해 목록의 컴포넌트에 액세스할 수 있습니다. 예를 들어, TableData로 이름 지정된 변수가 있고 해당 변수가 모두 Row로 이름 지정된 다수의 하위가 있습니다. 각 하위는 그 아래에 추가 데이터를 포함하고 있습니다(예: 이름 및 주소). 다음 코드를 지정하여 세 번째 행에서 이름에 액세스할 수 있습니다.
${Variables/TableData/Row[2]}
색인은 영(0) 기준이므로 색인 0은 첫 번째이고, 색인 1은 두 번째입니다.
변수 TableData에 다른 하위도 포함된 경우, 다른 모든 하위는 무시하고 위에서 세 번째 행을 선택하십시오. TableData의 세 번째 하위를 참조하려면 모든 참조를 나타내도록 별표(*)를 사용하십시오.
${Variables/TableData/*[2]}
색인 자체를 다른 변수로 지정할 수도 있습니다. 예를 들어, 테이블의 특정 행은 변수 RowIndex에 의해 지정됩니다. 현재 행은 다음 구문에 의해 지정될 수 있습니다.
${Variables/TableData/*[${Variables/RowIndex}]}
/ 문자를 사용하여 태그형 데이터 문자열을 따라 내려가며 요소에 액세스합니다. 또한 이 기술을 간접 참조와 결합하여 이름이 변수에 저장되는 하위 요소를 선택할 수도 있습니다. 예를 들어, 변수 Data가 하위 요소로 Name 및 Address를 가지고 변수 WhichOne이 자체 값으로 단어 Name 또는 단어 Address를 가지는 경우입니다. 따라서 다음 참조는 두 값 중 변수 WhichOne에 있는 값에 따라 ${Variables/Data/Name}에 저장된 값을 리턴하거나 ${Variables/Data/Address}에 저장된 값을 리턴합니다.
${Variables/Data/${Variables/WhichOne}}
이 기술이 결합될 수 있습니다. 색인 참조 나열 및 괄호 사용에 있는 테이블 데이터 예를 사용하십시오. 액세스할 열을 선택하는 추가 변수 ColumnName이 있는 경우 다음 구문은 선택된 행의 선택된 열에 대한 셀 데이터를 가져옵니다.
${Variables/TableData/*[${Variables/RowIndex]/@ColumnName}
서비스 호출 또는 메소드에 의해 리턴되고 변수에 저장된 IXml 오브젝트의 구조를 이동할 수 있습니다. 다음 예제는 XML 문서 내에서 요소를 찾는 필터를 작성하기 위해 사용할 수 있는 기술을 설명합니다.
모든 예제는 다음 XML 코드 세그먼트 예제를 기초로 합니다.
<Employees>
<Employee age="25">
<Name>John Smith</Name>
<Address>14 Park Lane</Address>
<City>Portsmouth</City>
<State zip="03801">New Hampshire</State>
</Employee>
<Employee age="21">
<Name>Ted Jones</Name>
<Address>26 Harbor View</Address>
<City>Hampton</City>
<State zip="03802">New Hampshire</State>
</Employee>
<Employee age="35">
<Name>Jill Jeffries</Name>
<Address>100 Oak Lane</Address>
<City>Exeter</City>
<State zip="03803">New Hampshire</State>
</Employee>
<Employee age="40">
<Name>Josh Vanderwall</Name>
<Address>45 Maple Ave.</Address>
<City>Bedford</City>
<State zip="03804">Massachusetts</State>
</Employee>
</Employees>
다음 참조는 지정된 요소 이름을 찾습니다.
${Employees/Employee/Name}
이 표현식은 첫 번째 일치 요소를 리턴합니다. 이 예제에서 리턴된 요소는 <Name>John Smith</Name>입니다.
다음 참조는 이름이 Name인 요소의 두 번재 인스턴스를 찾습니다.
${Employees/Employee/Name[1]}
이 표현식은 영(0) 기준 색인 번호에 따라 지정된 일치 요소를 리턴합니다. 이 예제에서 리턴된 요소는 <Name>Ted Jones</Name>입니다.
이 상황에서는 간접 참조를 사용할 수도 있습니다. 예를 들어, 다음을 입력할 수 있습니다.
$Variables/Foo/Bar[${Variables/Index}]
이 표현식은 특정 색인의 변수에 저장된 요소를 찾습니다.
다음 참조는 Name의 요소 인스턴스를 찾습니다. 여기서 텍스트 값이 Jill Jeffries와 같습니다.
${Employees/Employee/[Name=Jill Jeffries]}
이 표현식은 요소 텍스트에 따라 지정된 일치 요소를 리턴합니다. 이 예제에서 리턴된 요소는 <Name>Jill Jeffries</Name>입니다.
다음 표현식은 지정된 속성 값이 40인 Employee의 인스턴스를 찾습니다.
${Employees/Employee[@age=40]}
이 표현식은 속성 텍스트에 따라 지정된 일치 요소를 리턴합니다. 이 예제에서 리턴된 요소는 다음과 같습니다.
<Employee age="40">
<Name>Josh Vanderwall</Name>
<Address>45 Maple Ave.</Address>
<City>Bedford</City>
<State>Massachusetts</State>
</Employee>
두 번째 레벨 요소를 알 수 없는 Name의 인스턴스를 찾으려면 와일드카드 *를 사용하여 요소 이름을 지정하십시오.
${Employees/*[2]/Name}
이 표현식은 색인 번호에 따라 지정된 일치 요소를 리턴합니다. 이 예제에서 리턴된 요소는 다음과 같습니다.
<Name>Jill Jeffries</Name>
다음 구문은 지정된 속성 zip 값이 03804인 State의 상위 요소를 찾습니다.
${Employees/Employee/State[@zip=03804]/..}
이 표현식은 속성 텍스트에 따라 지정된 일치 상위 요소를 리턴합니다. 이 예제에서 리턴된 요소는 다음과 같습니다.
<Employee age="40">
<Name>Josh Vanderwall</Name>
<Address>45 Maple Ave.</Address>
<City>Bedford</City>
<State zip="03804">Massachusetts</State>
</Employee>
이 정보는 모델 조치 실행 방법을 설명합니다.
모델 인스턴스를 작성하고 해당 모델 인스턴스에 대한 WebAppAccess 오브젝트를 검색하고 모델의 main 메소드를 호출하여 다른 모델을 실행할 수 있습니다.getModelInstance() 메소드는 다음 세 인수를 취합니다.
둘 이상의 프로파일 이름을 지정하려면 프로파일 이름을 더하기 부호(+)로 구분하십시오(예: ProfileSetName!ProfileName+ProfileSetName!ProfileName).
Web Experience Factory는 세션당 단독 모델을 한 번 인스턴스 작성합니다. 비단독 모델의 경우 Web Experience Factory는 각 요청에 대해 해당 모델을 인스턴스 작성합니다.
다음 코드 샘플은 메소드에서 다른 모델을 실행하는 방법을 보여줍니다.
WebAppAccess remoteWebAppAccess =
webAppAccess.getModelInstance("myModels/ModelName", "Region!Southwest", "false");
remoteWebAppAccess.callMethod("main");
현재 WebAppAccess 오브젝트에서 processPage() 메소드를 호출하여 간단하게 현재 모델의 페이지를 표시할 수 있습니다.
webAppAccess.processPage("pageName");
링크된 모델의 페이지를 표시하려면 다음과 비슷하게 processPage()를 호출합니다.
webAppAccess.processPage("LinkedModelName.pageName");
다른 모델의 페이지를 표시하려면 메소드에서 다른 모델을 실행하기 위한 코드를 확인하십시오. remoteWebAppAccess 오브젝트에서 callMethod()를 호출하는 대신 processPage()를 호출하고 페이지 이름을 인수로 제공하십시오.
webAppAccess.processAction("ServiceCallName.invoke");
webAppAccess.processAction("ActionListName");
callMethod() 메소드를 사용하여 현재 모델 또는 링크된 모델에서 메소드를 호출할 수 있습니다. 아래 표시된 것처럼 메소드 이름을 지정한 후 쉼표로 구분된 목록으로 메소드에 인수를 전달할 수 있습니다.
URL을 통해 인수를 취하는 메소드를 직접 실행할 수 없습니다. 그러나 인수를 이름/값 쌍으로 URL에 추가하고 웹 애플리케이션의 RequestData 오브젝트에서 해당 인수 값을 추출할 수 있습니다. 아래 코드 샘플은 다음 URL에서 전달되는 인수 값을 추출합니다.
http://localhost:7001/Factory/webengine/URLTester/Action!MethodFielder?name=Tom&id=111?method=MethodWithArgsLJO 클래스에 있는 메소드의 본문:
public void MethodFielder(WebAppAccess webAppAccess) {
String name = webAppAccess.getRequestInputs().getInputValue("name");
String id = webAppAccess.getRequestInputs().getInputValue("id");
String method = webAppAccess.getRequestInputs().getInputValue("method");
webAppAccess.getVariables().setString("Name", name);
webAppAccess.getVariables().setString("ID", id);
webAppAccess.callMethod(method, name, id);
}
LJO 메소드 및 메소드 빌더 호출은 FORM POST 또는 URL 조회 매개변수, RequestInputs 인터페이스 또는 메소드에 대한 직접 인수에 의해 제출된 입력에 액세스합니다.
URL을 통해 호출되는 메소드는 인수를 갖지 않거나 WebAppAccess 인수만 가져야 하며, RequestInputs 인터페이스를 통해 HTTP 요청에서 입력을 검색해야 합니다.
웹 애플리케이션 요청에 대한 RequestInputs의 현재 인스턴스에 대한 참조를 검색하려면 다음을 호출합니다.
RequestInputs requestInputs = webAppAccess.getRequestInputs();
예를 들어 선택란 그룹 입력의 모든 입력을 가져오기 위해 다음과 유사한 작업을 수행할 수 있습니다.
Iterator inputs = webAppAccess.getRequestInputs().getInputValues("MyCheckboxGroup");
while(inputs.hasNext()) {
//process input values here
}
세션에 속성을 설정하고 해당 속성에 대한 값을 모델 사이에 공유하려는 오브젝트로서 지정하여 세션에 오브젝트를 저장할 수 있습니다.
webAppAccess.getHttpServletRequest().getSession().put("companyname", webAppAccess.getVariables().getText("companyname"));
String companyName = webAppAccess.getHttpServletRequest().getSession().get("companyname");
webAppAccess.getHttpServletRequest().getSession().remove("companyname");
메소드는 양식 입력 처리, 웹 애플리케이션(심지어 다른 웹 애플리케이션)의 다른 파트 실행 및 웹 애플리케이션이 사용자가 원하는 방법으로 기능하기 위해 필요한 다른 모든 논리 수행 작업을 수행합니다.
메소드에서 사용되는 기본 오브젝트는 WebAppAccess 오브젝트로, com.bowstreet.webapp.WebAppAccess 클래스의 인스턴스입니다. WebAppAccess 오브젝트는 com.bowstreet.webapp.WebApp 클래스의 인스턴스인 웹 애플리케이션 오브젝트에 의해 표시되는 웹 애플리케이션의 구조에 대한 프록시 기능을 수행합니다.
현재 모델 또는 다른 모델의 조치에 대한 URL을 생성할 수 있습니다.
webAppAccess.getActionURL("actionName");
/appcontext/servletname/models/path/to/models/Action!actionName
여기서, /MyApp/webengine/test/TestModel/Action!getCustomers
webAppAccess.getURLMapper().getURL("ModelName", "GetCustomers", "Region!Northeast$ServiceLevel!Gold", null);
/MyApp/webengine/method/MethodTest2/
Action!main/Profile!Region!Northeast$ServiceLevel!Gold
cluster.properties 및 bowstreet.properties 파일에 저장된 IBM Web Experience Factory 특성의 값을 가져올 수 있습니다.
webAppAccess.getSystemProperties()에 대한 호출에 의해 리턴되는 com.bowstreet.util.SystemProperties 오브젝트에 액세스하십시오. SystemProperties 오브젝트를 사용하면 문서 루트에 대한 디렉토리 경로, 서버에 대한 URL 및 기타 정보와 같은 정보에 액세스할 수 있습니다. 다음 메소드를 호출하십시오.
AppServerDeployDir\MyApp.ear\MyApp.war
AppServerDeployDir\MyApp.ear\MyApp.war\WEB-INF
http://127.0.0.1:9080/MyApp
http://127.0.0.1:9080/MyApp/webengine
webAppAccess.getVariables() 메소드를 호출하여 웹 애플리케이션의 모든 변수에 액세스할 수 있습니다.
webAppAccess.getVariables().getXmlElement("VariableTest", "customers/customer[1]");
다음 코드 샘플은 <customers /> 구조에서 두 번째 <customer /> 요소를 제거합니다.
IXml customers = webAppAccess.getVariables().getXml("CustomerList");
customers.removeChildElement(customers.findElement("customers/customer[1]"));
IXml customers = webAppAccess.getVariables().getXml("CustomerList");
customers.setText("customers/customer[2]/name", "NewName");
webAppAccess.getHttpServletRequest() 메소드를 호출하여 HttpServletRequest 오브젝트에 액세스할 수 있습니다.
공용 메소드의 전체 설명에 대해서는 JDK 설치의 javax.servlet.http.HttpServletRequest 클래스에 대한 Javadoc을 확인하십시오.
HttpServletResponse 오브젝트를 사용하여 메소드에 의해 리턴되는 데이터의 컨텐츠 유형을 수정하십시오.
이 오브젝트는 텍스트 또는 html이 아닌 다른 대상에 응답의 ContentType을 설정합니다.
또한 응답에 헤더를 추가하거나 클라이언트에 대한 응답을 수정할 수 있습니다.
예를 들어 다음 코드 샘플은 Microsoft Excel 스프레드시트를 리턴하기 위해 응답의 ContentType을 설정합니다.
public void setContentTypeXL(WebAppAccess webAppAccess) {
webAppAccess.getHttpServletResponse().setContentType("application/msexcel") ;
try {
File excelSheet = new File(webAppAccess.getSystemProperties().getDocumentRoot()+
File.separator + "Schedule.xls");
int numFileBytes = (int)excelSheet.length();
byte[] fileBytes = new byte[numFileBytes];
BufferedInputStream bis = new BufferedInputStream(new FileInputStream(excelSheet));
int i = 0;
while(i < numFileBytes){
fileBytes[i] = (byte)bis.read();
i++;
}
webAppAccess.getHttpServletResponse().getOutputStream().write(fileBytes);
}
catch (IOException ioe) {
System.out.println(ioe+"Cannot find file.");
}
}
공용 메소드의 전체 설명에 대해서는 JDK 설치의 javax.servlet.http.HttpServletResponse 클래스에 대한 JavaDoc을 확인하십시오.
다음 유형 중 하나로 변수를 지정할 수 있습니다.
<customers>
<customer>
<name>Jane</name>
<id>1112</id>
</customer>
<customer>
<name>Jane</name>
<id>1112</id>
</customer>
</customers>
스키마에서 정의한 유형으로 변수를 지정할 수도 있습니다. 이러한 유형은 변수 유형 선택기에 표시됩니다. 스키마에서 정의한 유형을 선택하는 경우, 스키마의 Element 폴더가 아닌 Type 폴더에서 유형을 선택해야 합니다.
참조 선택기를 사용하여 중첩된 간접 참조를 작성하십시오.
를 클릭하십시오. 참조 선택기 창이 열립니다.여러 빌더가 테이블에서 입력을 제공하며 이러한 테이블에서 관련 입력 값을 제거하기 위해 행을 삭제할 수 있습니다.
빌더 입력(예: 조치 목록 빌더)의 테이블에서 행을 제거하는 경우 행과 관련된 입력이 널(null)로 간주되지 않도록 올바른 기술을 사용해야 합니다.
행을 제거하지 않고 행의 컨텐츠를 삭제하면 빌더가 입력을 널(null)로 간주합니다.
IBM Web Experience Factory Designer 창과 분리된 창에서 빌더 호출 편집기를 열 수 있습니다.
다음에 Workbench를 시작하고 모델에 빌더를 추가할 때 빌더 호출 편집기가 분리 창에서 열립니다.
Web Experience Factory Designer를 종료하지 않아도 정보 소스에서 웹 피드를 표시할 수 있습니다.
Web Experience Factory 웹 자원 보기를 통해 추가 제품 정보 및 자원(예: 제품 위키)에 연결할 수 있습니다.
Web Experience Factory 웹 자원 보기를 열면 내부 Eclipse 브라우저를 통해 인터넷에 있는 Web Experience Factory 제품 위키에 연결됩니다. 기본적으로 브라우저는 제품 위키의 홈 페이지에서 열립니다. 이 홈 페이지에는 Web Experience Factory 제품군 관련 유용한 권장사항이 수록된 기사 등의 정보 카테고리에 대한 링크가 있습니다. 제품 정보 소스 및 기타 관련 위키에 대한 링크도 있습니다.
제품 위키에서는 커뮤니티 구성원이 경험을 바탕으로 한 전문 지식을 제공합니다. 커뮤니티에는 고객, 비즈니스 파트너 및 세계 각지의 IBM 사용자가 포함됩니다. 활성 커뮤니티의 경험을 통해 학습할 수 있을 뿐만 아니라 자신의 지식을 커뮤니티와 공유할 수도 있습니다.
Web Experience Factory 웹 자원 보기의 맨 위에 있는 도구 모음은 기타 자원을 나열합니다. 예를 들어, 애플리케이션에 사용할 수 있는 기술에 대한 샘플과 기술이 포함된 위키 섹션인 샘플 및 기술을 클릭할 수 있습니다. 도구 모음의 아이콘은 브라우저에서 탐색하는 데 사용됩니다.
도움말 메뉴를 사용하여 Web Experience Factory 웹 자원 보기에 액세스할 수도 있습니다. 를 클릭한 후 옵션 중 하나를 선택하십시오.
자원 로그 보기는 현재 프로젝트 세션에서 중요한 이벤트를 표시합니다.
이 보기에서는 이 Eclipse 세션에서 수행한 마지막 기능 세트(또는 웹 애플리케이션) 추가/제거 조작의 결과를 표시합니다. 이 보기에서는 프로젝트에서 제거, 수정 및 추가된 모든 파일 목록 및 최근 복사 또는 제거 조작으로 변경된 사항이 적용된 결과 발생하는 오류를 표시합니다. 이 보기를 사용하여 현재 개발 세션에서 발생한 활동을 추적하십시오. Eclipse를 다시 시작하면 보기가 지워집니다.
를 클릭하여 보기를 표시하십시오. 이 보기는 Web Experience Factory 퍼스펙티브의 태스크 보기 영역에서 열립니다.
보기 메뉴에서는 필터링 및 복사 옵션을 제공합니다. 이 보기에 표시된 이벤트 세트는 보기 메뉴에서 사용 가능한 다음과 같은 필터링 유형으로 분류됩니다.
이벤트 필터링 옵션 이외에도 자원 로그 보기 팝업 메뉴에서는 복사 조작을 제공합니다. 복사는 클립보드에 보기 컨텐츠를 텍스트로 배치합니다(리턴 및 줄 바꾸기 문자 조합으로 행 구분).
복사는 프로젝트 활동에 대한 포괄적인 기록을 제공하는 데 편리합니다. 예를 들어, 여러 파일을 겹쳐써야 하지만 어떤 이유로든 겹쳐쓰기에 실패한 경우 복사를 통해 향후 참조할 해당 파일 목록을 가져올 수 있습니다. 또한 파일 이름을 수동으로 다른 명령에 복사 및 붙여넣어 겹쳐쓰기 프로세스를 완료할 수 있습니다.
보기에서 렌더링되는 방법과 함께 보기에 로그된 모든 이벤트 유형을 제공합니다.
IBM Web Experience Factory 모델 구성 유형을 작성할 수 있습니다.
IBM Web Experience Factory Designer에서 실행 구성 특성을 설정할 수 있습니다.
특성은 Web Experience Factory Designer 내에서 모델을 실행할 때 사용됩니다.
표준 Eclipse 실행 구성 대화 상자를 사용하여 Eclipse 환경 내에서 프로그램을 실행할 때 사용되는 매개변수를 정의할 수 있습니다. 모델 실행은 별개의 실행 구성 유형입니다. 따라서 모델을 실행하기 전에 Factory Model 유형의 새 실행 구성을 정의해야 합니다.
다음으로 실행하도록 Factory Model 유형을 구성할 수 있습니다.
실행 구성의 일부로 모델을 실행하는 Web Experience Factory 서버 및 사용할 브라우저 유형에 대한 정보를 제공합니다. 또한 Web Experience Factory 서버 추적 켜기 여부를 지정할 수 있습니다.
다음 표는 실행 구성 대화 상자의 다양한 탭에서 설정할 수 있는 특성 값에 대해 설명합니다.
| 기본 탭 | 설명 |
|---|---|
| 실행할 모델 | 두 가지 모드 중 하나로
팩토리 모델 유형을 구성할 수 있습니다.
참고: 이름 지정된 모델의 실행 모드를 선택할 때
프로젝트도 선택해야 합니다.
|
| 서버 탭 | 설명 |
| 서버 호스트 | 연결하려는 IBM Web Experience Factory 서블릿을 실행 중인 서버의 호스트 이름을 입력하십시오. Web Experience Factory 서블릿과 Web Experience Factory Designer가 같은 시스템에 있으면 localhost를 사용할 수 있습니다. |
| 서버 포트 | Web Experience
Factory에
요청을 청취하는 포트 번호를 입력하십시오. 예: 9080 |
| 브라우저 탭 | 설명 |
| 브라우저 명령 | 모델 실행 시 실행할 웹 브라우저에 대한 경로를 입력하십시오. |
| 추적 탭 | 설명 |
| 시스템 추적을 사용하여 실행 | 모델을 실행할 때마다 메소드 및 페이지 조치에 대한 시스템 추적 정보를 출력하려면 이 선택란을 사용하십시오. |
| 공통 탭 | 설명 |
| 실행 구성 유형 | 이 필드는 실행 구성
설정과 함께 파일의 위치를 정의합니다.
|
| 전환하거나 실행될 때 열리는 퍼스펙티브 | 모델이 실행 모드에서
실행됩니다(디버그 모드는 지원되지 않음). 실행 모드의 경우, 프로그램을
실행하지만 실행이 일시중지 또는 검사되지 않을 수 있습니다. 이 필드를 사용하면 실행 구성이 실행될 때 퍼스펙티브가 활성화되도록 할 수 있습니다. |
| 즐겨찾기 메뉴에 표시 | 실행 구성이 실행 즐겨찾기 목록에 표시됨을 지정하려면 실행 상자를 선택하십시오. |
서버 구성을 변경해야 하는 경우가 있습니다.
IBM Web Experience Factory 모델 구성 유형을 삭제하려면 다음을 수행하십시오.
개발자 간에 프로젝트 자원을 공유할 수 있습니다.
IBM Web Experience Factory 아카이브 파일을 작성하거나 설치할 수 있습니다. 아카이브 파일은 Web Experience Factory 내보내기/가져오기 마법사를 사용하여 작성하는 특수한 압축 파일입니다. 이 마법사는 Web Experience Factory Designer의 및 메뉴에 통합되었습니다. 아카이브는 프로젝트 컴포넌트를 쉽게 수집하고 분배하는 방법을 제공합니다.
IBM Web Experience Factory Designer는 프로젝트 자원을 내보내고 가져오는 데 사용할 수 있는 마법사를 제공합니다.
다른 개발자와 자원을 공유할 수 있도록 프로젝트 자원을 내보내고 가져올 수 있습니다. 이 마법사를 사용하여 Web Experience Factory 아카이브 Zip 파일을 작성할 수 있습니다.
Web Experience Factory 아카이브는 공유할 자원을 패키지하는 데 사용하는 Zip 파일입니다. 이 파일은 Web Experience Factory 내보내기 마법사에서 자동으로 작성됩니다. 이러한 특수 목적의 마법사는 Eclipse 내보내기/가져오기 메뉴에 통합됩니다.
아카이브 파일에 저장된 모든 자원은 프로젝트 서비스 가능 컨텐츠 디렉토리(프로젝트 루트 디렉토리)에 상대적입니다.
개발 서버에 공개하거나 완료된 프로젝트를 프로덕션 서버로 내보내는 경우 IBM Web Experience Factory 애플리케이션은 설계 시에 애플리케이션을 재생성하는 데 사용하는 조합된 파일 세트에 불과합니다.
대부분의 포틀릿, 웹 애플리케이션 및 위젯처럼 Web Experience Factory 애플리케이션도 WAR로 분배(또는 공개)됩니다.
애플리케이션 실행에 필요한 모든 내용인 WAR 빌드 프로세스에 패키지되어 있습니다(프로파일 세트 포함). 그렇기 때문에 자체 포함 WAR 파일은 적절한 모든 서버에 분배되거나 공개되어 실행될 수 있습니다.
해당 프로젝트 구조를 소스 제어용으로 변환할 때 두 가지 기본 접근 방식이 사용 가능합니다.
이 접근 방식은 프로젝트에 하나의 느슨한 연결(예: http 연결)만 있는 경우에 유용합니다. 아티팩트 이름을 선택하여 작성된 아티팩트를 실제로 사용하는 경우(공통 빌드에서) 충돌을 방지해야 합니다. 공통 빌드가 있는 경우 빌드 프로세스가 필요합니다.
이 접근 방식은 여러 사람이 애플리케이션의 다른 파트에 대해 작업하는 경우에 유용하게 사용됩니다. 개발자 각각은 Web Experience Factory 사본을 가지고 자신의 작업을 공통 소스 제어 영역에서 확인합니다. 모든 팀 구성원은 필요할 경우 용이하게 자신의 프로젝트를 모든 아티팩트로 채울 수 있으며, 충돌의 이름을 지정하여 이를 더욱 방지할 수 있습니다.
두 경우 모두 소스 제어에서 프로젝트 구조를 미러링하여 소스 제어 시스템과 프로젝트의 트래픽을 줄일 수 있습니다.
애플리케이션을 장기로 다시 작성하는 기능이 필요한 경우 프로젝트에서 사용되는 모든 아티팩트를 캡처하는 것이 중요합니다.
프로젝트 레벨에는 버전을 제어해야 하는 다음과 같은 선택사항이 있습니다.
소스 파일과 생성된 파일만 프로젝트에 남게 됩니다. 생성된 파일에서 확인하거나(권장되지 않음) 동일한 환경을 다시 만들려는 경우 소스에서 나중에 쉽게 작성할 수 있습니다. 생성된 파일은 WEB-INF/factory/generated/ 폴더에 있습니다. 이 기술을 사용하여 소스 제어에 소스 파일을 포함하고 각 개발자가 프로젝트에 필요한 Web Experience Factory 및 다른 운송 소프트웨어의 동일한 버전을 설치할 수 있습니다.
소스 제어에 공유 팀 프로젝트를 사용하고 새 파일이나 수정된 파일만 체크인하는 경우 팀 구성원 간에 공유하고 수정하지 않으려는 모든 아티팩트(Jar, 빌더 정의, 특성)를 포함하는 소스 제어 시스템에 원형 프로젝트를 설정하십시오. 원형 프로젝트 및 공유 팀 프로젝트를 결합하여 새 팀 구성원을 위한 프로젝트를 작성해 줄 수 있습니다. 물론 이 두 차원에는 여러 변이가 가능합니다(캡처할 내용이나 표시하는 방법 등).
소스 제어 시스템에서 반드시 다음 프로젝트 아티팩트는 저장해야 합니다.
다음 아티팩트를 소스 제어에서 캡처하거나 저장하지 마십시오.
IBM Web Experience Factory는 소스 제어에서 제외된 파일의 기본 선택을 제공합니다.
Eclipse 개발 환경은 소스 제어에서 기본적으로 제외되는 폴더 및 파일 설정을 지원합니다. Web Experience Factory는 소스 제어에서 제외되는 폴더 및 파일의 목록을 제공하여 Eclipse의 표준 팀 기능과 통합합니다. 목록을 보려면 Eclipse에서 을 클릭하고 */WebContent로 시작하는 항목을 참고하십시오. 이러한 항목은 기본적으로 Web Experience Factory에서 제공됩니다.
환경 설정 대화 상자에서 제어를 사용하여 프로젝트의 필요에 따라 목록을 수정할 수 있습니다. 또한 사용하는 소스 제어 명령을 통해 목록의 모든 항목을 대체할 수 있습니다.
이 문서는 IBM Web Experience Factory 시스템에서 웹 애플리케이션 오브젝트의 구조 및 작동에 대해 설명합니다.
이 문서의 정보는 아래와 같은 사용자를 대상으로 합니다.
웹 애플리케이션은 웹 애플리케이션 파라메트릭 모델 생성의 실행 결과입니다. 웹 애플리케이션 요소는 빌더에서 애플리케이션 생성 시에 사용 가능한 기본이 되는 빌딩 블럭입니다.
웹 애플리케이션은 J2EE 웹 애플리케이션 전체 또는 일부를 나타내며 여기에는 다음이 포함됩니다.
이 정보에서는 웹 애플리케이션 런타임 환경 프로세스와 웹 애플리케이션 개발자가 사용하는 API에 대해 설명합니다.
웹 애플리케이션의 실행 경로 및 실행 시간 조치를 이해해야 합니다.
내부적으로 웹 애플리케이션 실행에서 처리되는 두 가지 유형의 조치가 있습니다.
웹 애플리케이션 런타임 환경에 대해 더 자세히 알려면 개별적인 요청의 실행 경로를 이해하는 것이 도움이 됩니다.
다음은 동일한 요청자에 대해 작성한 웹 애플리케이션 요청의 후속 요청에 대한 상위 레벨 단계입니다.
WebAppAccess는 애플리케이션을 실행시키는 프로그래머의 인터페이스입니다.
이 인터페이스를 사용하여 프로그래머는 변수, 링크된 모델 및 링크된 Java 오브젝트와 같은 인스턴스 고유 런타임 컴포넌트 모두에 액세스하고 수정할 수 있습니다. 수정할 수 없는 컴포넌트(읽기 전용)는 페이지, 메소드, 시스템 이벤트 핸들러 및 오류 핸들러이며 웹 애플리케이션 인터페이스를 통해 액세스할 수 있습니다. WebAppAccess 인터페이스 API는 메소드, LJO 및 JSP 페이지에서 개발자가 사용할 수 있습니다. 웹 애플리케이션, 변수 및 링크된 모델은 WebAppAccess API를 통해 액세스할 수 있습니다.
IBM Web Experience Factory에서는 다음과 같은 여러 가지 방법으로 Java 코드를 애플리케이션에 통합할 수 있습니다.
WebAppAccess 오브젝트를 사용하여 Web Experience Factory 런타임 및 API를 프로그래밍할 수 있습니다. Web Experience Factory에서 Java 사용에 대한 자세한 정보는 제품 위키에서 웹 애플리케이션에서 Java 사용 기사를 참조하십시오.
웹 애플리케이션은 생성 프로세스 결과입니다. 작성한 모델이 프로파일화된 경우, 웹 애플리케이션의 고유 버전이 필요에 따라 작성됩니다. 웹 애플리케이션에는 애플리케이션 실행에 필요한 구조화된 데이터 전체가 포함됩니다.
웹 애플리케이션에 포함된 컴포넌트는 페이지, 메소드, 조치 목록, 변수, 링크된 Java 오브젝트, 링크된 모델, 시스템 이벤트 리스너 및 오류 핸들러입니다.
WebAppAccess가 처음으로 인스턴스로 작성되는 경우, 웹 애플리케이션의 런타임으로 수정 가능한 컴포넌트는 웹 애플리케이션에서 WebAppAccess 오브젝트로 복사됩니다. 이러한 컴포넌트는 변수, 링크된 모델 및 링크된 Java 오브젝트입니다. 이를 사용하여 WebAppAccess는 공유된 웹 애플리케이션 오브젝트를 손상시키지 않으면서 해당 항목을 수정할 수 있습니다
WebApp webApp = webAppAccess.getWebApp();
링크된 모델은 웹 애플리케이션 개발자가 다른 웹 애플리케이션에서 모델 기능을 재사용하고 공유할 수 있게 해주는 메커니즘을 제공합니다.
모델을 링크하여 메소드 또는 페이지와 같은 링크된 모델의 공용 기능 링크를 요청하는 모델에 노출됩니다.
링크된 모델을 추가하려면 링크된 모델 빌더를 사용하여 링크할 모델을 지정해야 합니다. 링크된 모델 빌더는 이름이 지정된 슬롯을 모델에 추가하며, 여기에는 링크되는 모델 정보가 포함됩니다. 아래 예제에서는 LM1을 로컬로 링크된 모델 참조 이름으로 사용하여 모델 A를 모델 B에 링크하는 것을 보여줍니다.
빌더 이름은 링크된 모델 기능에 액세스할 때 사용해야 하는 접두부 이름으로 사용됩니다. 예를 들어, LM1을 빌더 이름으로 지정한 링크된 모델을 추가한 경우 링크된 모델 빌더 이름, 마침표(.) 구분 기호 및 페이지 이름을 사용하여 해당 모델에서 페이지를 참조합니다.
webAppAccess.processPage("LM1.HomePage");
링크된 모델에서 메소드를 호출할 때에도 비슷한 형식을 사용합니다.
String value = webAppAccess.callMethod("LM1.doWork");
모델이 링크되는 경우, 세션에서 공유되는 모델의 인스턴스를 하나만 작성하거나 링크된 모델이 세션에서 공유되지 않도록 지정할 수 있습니다. 링크된 모델이 공유되지 않는 경우 둘 이상의 링크된 모델 빌더에서 사용되면 모델의 인스턴스가 여러 개 작성됩니다.
링크된 모델이 비 단독 세션으로 지정되면 이 모델의 여러 인스턴스가 해당 요청자 세션에서 작성됩니다.
동일한 모델을 참조하는 다른 링크된 모델은 자체 고유한 인스턴스를 갖습니다. 비 단독 모드에서 링크된 모델은 요청자 세션에 저장되지는 않지만 대신 해당 모델을 링크한 모델에 참조로 유지됩니다. 예를 들어, 모델 A 및 모델 B가 모델 C에 연결되는 경우 모델 C의 인스턴스 두 개가 주어진 세션에 작성됩니다. 상위 모델의 링크된 모델 슬롯은 각 인스턴스를 참조합니다.
모델 C의 인스턴스가 여러 개 있기 때문에 사용자 세션에서 이에 대한 참조는 없고 모델 C 페이지의 링크는 체인에서 최상위 단독 상위 모델을 가리켜야 합니다. 예를 들어, 모델 doWork 메소드로의 링크를 포함하는 HomePage의 경우 링크는 다음과 같습니다.
/webengin/A/Action:LM1.doWork
다른 링크된 모델을 추가하고 모델 C는 모델 D에 링크되며 모델 D의 페이지를 main 메소드에 링크하려는 경우 링크는 다음과 같습니다.
/webengin/A/Action:LM1.LM2.main
이 예제에서 LM2는 모델 C에 추가되는 링크된 모델의 빌더 이름입니다.
링크된 모델이 단독 세션으로 지정되면 이 모델의 인스턴스는 해당 세션에서 하나만 작성됩니다.
모델 C의 인스턴스 하나만 있고 요청자 세션에는 이에 대한 참조가 포함되어 있기 때문에 모델 C 페이지로의 링크는 내부 조치에 대해 모델 C 자체를 직접 가리킬 수 있습니다. 예를 들어, 모델 doWork 메소드로의 링크를 포함하는 HomePage의 경우 링크는 다음과 같습니다.
/webengin/C/Action:doWork
링크된 모델의 WebAppAccess는 링크된 모델 슬롯에 연관된 인스턴스로 작성된 모델을 설정하거나 변경하는 데 사용할 수 있습니다.
// create or get a singleton instance of model "C"
WebAppAccess modelC = webAppAccess.getModelInstance("C", null, true);
// Get the linked model slot holder
LinkedModel linkedModel = webAppAccess.getLinkedModel("LM1");
// Now set the instance on the linked model slot
linkedModel.setLinkedModelInstance(modelC);
LM1이 호출되면 새 모델로 이동합니다. 여기에서는 링크된 모델이 스왑되면 호출된 동일한 메소드/페이지를 포함하는 모델로 링크된 모델을 바꾼다고 가정합니다.
어떤 경우 링크된 모델의 참조를 해지하여 JVM 가비지 콜렉션이 링크된 모델에서 사용하던 메모리를 다시 사용할 수 있게 됩니다.
웹 애플리케이션 메소드 및 조치 목록은 모든 웹 애플리케이션 메소드 및 조치 목록을 나타내는 생성된 Java 클래스로 변환됩니다.
웹 애플리케이션의 각 고유 인스턴스에 대해 한 개의 Java 클래스가 생성됩니다. 생성된 클래스 이름은 웹 애플리케이션 이름 + 고유 접미부(웹 애플리케이션 생성에 사용되는 프로파일 데이터 지정에 사용)로 구성됩니다.
웹 애플리케이션 메소드나 다른 LJO에 있는 경우 다음 두 가지 방식 중 하나로 LJO 메소드를 호출할 수 있습니다.
webAppAccess.callMethod("MyLJO.doWork", "foo");
이 예제에서 doWork의 실제 서명은 다음과 같습니다.
public void doWork(WebAppAccess webAppAccess, String name);
callMethod(..)를 통해 호출하면 WebAppAccess를 자동으로 첫 번째 인수로 전달합니다.
다음과 같이 LJO 인스턴스를 가져오고 직접 호출할 수 있습니다.
SampleLJO myLJO = (SampleLJO)webAppAccess.getVariables().getObject("MyLJO");
myLJO.doWork(webAppAccess, "foo");
LJO가 생성된 메소드 클래스의 기본 클래스로 사용되도록 지정된 경우 링크된 오브젝트 빌더 이름을 접두부로 사용하지 않고("MyLJO" 사용 안함) 메소드를 직접 호출할 수 있습니다.
webAppAccess.callMethod("doWork", "foo");
웹 애플리케이션 메소드에 대해 수행했던 것처럼 메소드 이름을 제외하고 WebAppAccess callMethod(..) 메소드를 사용하여 링크된 모델 LJO 메소드를 호출할 수 있는 웹 애플리케이션 메소드나 LJO에 있는 경우, 링크된 모델 빌더 호출 이름과 링크된 모델의 LJO 빌더 호출 이름 및 LJO 메소드 이름을 모두 지정해야 합니다.
webAppAccess.callMethod("MyLinkedModel.MyLJO.doWork", "foo");
이 예제에서 doWork의 실제 서명은 다음과 같습니다.
public void doWork(WebAppAccess webAppAccess, String name);
callMethod(..) 메소드를 통해 호출하면 WebAppAccess를 자동으로 첫 번째 인수로 전달합니다.
다음과 같이 링크된 모델의 인스턴스를 가져오고 링크된 모델 WebAppAccess의 callMethod(..)를 사용할 수 있습니다.
WebAppAccess linkedWebAppAccess = webAppAccess.getLinkedModel("MyLinkedModel");
linkedWebAppAccess.callMethod("MyLJO.doWork", "foo");
또는, 직접 LJO 인스턴스로 가서 호출할 수도 있습니다.
WebAppAccess linkedWebAppAccess = webAppAccess.getLinkedModel("MyLinkedModel");
SampleLJO myLJO = (SampleLJO)linkedWebAppAccess.getVariables().getObject("MyLJO");
myLJO.doWork(linkedWebAppAccess, "foo");
Java 코드에서 메소드를 호출하는 작업은 호출하는 대상에 따라 두 가지 방식으로 수행할 수 있습니다.
webAppAccess.callMethod("doWork", "foo");
public void doWork(WebAppAccess webAppAccess, String name);
callMethod(..) 메소드를 통해 호출하면 WebAppAccess를 자동으로 첫 번째 인수로 전달합니다.
doWork(webAppAccess, "foo");
웹 애플리케이션 메소드나 LJO에 있는 경우 웹 애플리케이션 메소드에 대해 수행했던 것처럼 메소드 이름을 제외하고 WebAppAccess callMethod(..) 메소드를 사용하여 링크된 모델 메소드를 호출할 수 있습니다. 이때 링크된 모델 빌더 호출 이름과 메소드 이름을 모두 지정해야 합니다.
webAppAccess.callMethod("MyLinkedModel.doWork", "foo");
이 예제에서 doWork의 실제 서명은 다음과 같습니다.
public void doWork(WebAppAccess webAppAccess, String name);
callMethod(..) 메소드를 통해 호출하면 WebAppAccess를 자동으로 첫 번째 인수로 전달합니다.
IBM Web Experience Factory 애플리케이션이 기능을 위해 둘 이상의 모델을 사용하는 경우 한 모델에서 다른 모델로 데이터를 전송할 수 있습니다.
모델 사이에 통신하는 여러 가지 방법이 있습니다.
이벤트는 이벤트를 청취하는 세션(예: 동일 사용자에 대한)에서 모델에 도착하는 이름 지정된 브로드캐스트입니다. 이벤트 종류에는 일반 이벤트 및 위젯 이벤트 두 가지가 있습니다.
인수를 갖도록 이벤트를 선언할 수 있으며, 이벤트가 발생할 때 값이 지정됩니다. 일반 이벤트의 경우, 주어진 이벤트의 모든 사용자가 동일한 방식으로 이벤트를 선언하는 것이 중요합니다.
일반 이벤트의 경우, 이벤트 선언 빌더를 단일 모델에 배치한 후 해당 모델을 이벤트를 발생시키거나 처리할 다른 모델로 가져오십시오. 이벤트는 세션에서 이름 지정된 브로드캐스트입니다. 이벤트가 발생할 때 동일한 사용자를 실행 중인 다른 모델이 해당 이벤트를 포착할 수 있습니다.
직접 또는 가져온 모델 빌더를 통해 모델에 이벤트 선언 빌더를 포함시킬 때 빌더는 fireXxx(여기서 Xxx는 이벤트 이름임)라는 메소드를 웹 애플리케이션에 작성합니다. 이 메소드는 이벤트 선언 빌더에 정의된 대로 올바른 인수를 갖습니다.
이벤트를 처리하려면 이벤트 선언과 동일한 인수를 가진 메소드를 작성한 후 이벤트 핸들러 빌더를 작성하여 이름 지정된 해당 이벤트를 해당 메소드로 라우트하도록 시스템에 알리십시오. 일단 모델이 구체화되면, 모델은 해당 이벤트를 발생시키는 모델(자신 포함)을 청취합니다. 특정 모델(또는 모델 유형)이 존재함을 알고 있지만 이에 대한 직접 링크는 없는 경우 이벤트는 통신을 위한 좋은 기술입니다.
위젯 이벤트의 경우, 위젯 이벤트 빌더 입력을 사용하여 위젯이 이벤트를 발생시키거나 처리하는지 또는 둘 다를 수행하는지 여부를 지정하십시오. 동일한 대화 상자에서 이벤트를 처리할 방법을 지정하십시오.
세션 데이터를 단순 맵에 저장할 수 있으므로 두 개의 서로 다른 모델이 단지 동일한 키를 사용함으로써 동일한 오브젝트를 공유할 수 있습니다.
모델은 WebAppAccess 오브젝트에서 getWebAppData 메소드를 사용하여 세션에 데이터를 저장할 수 있습니다. 데이터는 단순 맵에 저장되므로 두 개의 서로 다른 모델이 단지 동일한 키를 사용하여 동일한 오브젝트를 공유할 수 있습니다.
링크된 모델에서 메소드를 사용하여 기본 모델에서 링크된 모델로 데이터를 전송하거나 링크된 모델에서 데이터를 검색하십시오.
하나의 모델이 링크된 모델 빌더를 사용하여 다른 모델을 참조하는 경우, 첫 번째 모델은 자체 메소드에 액세스하는 것과 동일한 방법으로 링크된 모델의 공용 메소드에 액세스할 수 있습니다.
기본 모델은 <링크된 모델 이름>.<공용 메소드 이름>으로 공용 메소드를 지정하여 조치 목록 또는 메소드에서 공용 메소드를 호출합니다.
링크된 모델에서 메소드를 사용하여 기본 모델에서 링크된 모델로 데이터를 전송하거나 링크된 모델에서 데이터를 검색할 수 있습니다.
IBM은 나이나 능력에 관계 없이 모든 사용자가 액세스할 수 있는 제품을 제공하려고 노력하고 있습니다.
이 제품은 표준 Microsoft Windows 탐색 키를 사용합니다.
IBM 및 내게 필요한 옵션에 대한 자세한 정보는 IBM Accessibility Center를 참조하십시오.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
DTD는 지원되는 문서 유형 선언을 가리킵니다. 내게 필요한 옵션 기능은 거동이 불편하거나 시각 장애를 가진 사용자가 IT 제품을 사용할 수 있도록 도와 줍니다.
Windows에서 읽기 쉽도록 구성된 글꼴 및 색상을 사용하려면 고대비 모드 설정을 사용하십시오. Eclipse는 Microsoft Windows XP 고대비 모드의 1152 x 864 해상도를 사용하는 고대비에 대해 테스트되었습니다. 테스트된 해상도 이상을 고대비 모드로 사용할 수 있습니다.
고대비 모드를 사용하려면 Windows 제어판을 열고 내게 필요한 옵션을 두 번 클릭하여 내게 필요한 옵션 대화 상자를 열고 디스플레이 탭을 클릭한 다음 고대비 사용을 선택하십시오.
Eclipse는 Eclipse Workbench에서 사용할 수 있는 키 바인딩 세트를 제공합니다. Eclipse는 명령을 호출하는 명령 및 키 조합의 연관과 같은 키 바인딩을 정의합니다. Web Experience Factory Designer에서 작업하는 중 사용할 수 있는 Eclipse 키 바인딩 목록을 보려면 를 클릭하거나 Ctrl+Shift+L을 입력하십시오. Eclipse 키 바인딩에 대한 자세한 정보는 도움말의 Workbench 사용자 안내서를 참조하십시오.
이 제품에서는 표준 Windows 탐색 키를 사용합니다. Eclipse의 키보드 탐색 및 내게 필요한 옵션 기능에 대한 정보는 도움말의 Workbench 사용자 안내서를 참조하십시오.
| 키보드 조합 | 조치 |
|---|---|
| F10 | 메뉴 표시줄의 메뉴 액세스 |
| 오른쪽 화살표 | 메뉴 표시줄에서 오른쪽으로 탐색 |
| 왼쪽 화살표 | 메뉴 표시줄에서 왼쪽으로 탐색 |
| 아래로 화살표 | 선택된 메뉴의 아래 메뉴 옵션으로 탐색 |
| 위로 화살표 | 선택된 메뉴의 위 메뉴 옵션으로 탐색 |
| Shift+F10 | 현재 보기로 컨텍스트 메뉴 열기 |
| Ctrl+F10 | 현재 보기로 드롭 다운 메뉴 열기 |
| Alt+니모닉 | 메뉴 표시줄의 니모닉 해당 메뉴 및 메뉴 옵션 열기 |
키보드 탐색으로 모든 보기 및 편집기 사이를 탐색할 수 있습니다. 보기 및 편집기 사이를 탐색할 때 Web Experience Factory Designer가 최근 선택된 항목을 기억하여 필요 시 두 항목 사이를 신속하게 탐색할 수 있습니다. 예를 들어 프로젝트 탐색기의 초점을 포함하고 빌더 호출 편집기를 열었으면 Ctrl+F7을 눌러 보기 메뉴를 활성화한 다음 보기 메뉴의 편집기를 선택하십시오. 빌더 호출 편집기에 초점이 포함되면 Ctrl+F7을 사용하여 프로젝트 탐색기 및 빌더 호출 편집기 사이에서 앞뒤로 토글할 수 있습니다.
| 키보드 조합 | 조치 |
|---|---|
| Ctrl+F6 | 편집기 메뉴 활성화 및 열기 편집기 사이 탐색 |
| Ctrl+F7 | 보기 메뉴 활성화 및 열기 보기 사이 탐색 |
| Ctrl+E | 열기 편집기 사이를 탐색하기 위해 편집기의 편집기 드롭 다운 메뉴를 활성화 |
| Ctrl+Page Up, Ctrl+Page Down | 퍼스펙티브의 모델 편집기 영역 내부에 있는 열기 탭 사이 탐색
탭은 애플리케이션 트리 패널 위의 막대나 빌더 호출 편집기 아래의 막대에 있을 수 있습니다. 키는 초점이 포함된 패널의 막대에서 작동합니다. |
| Alt+(-) | 보기 탭 이동, 보기 크기 수정, 빠른 보기에 액세스, 보기 분리, 최소화 및 최대화하기 위해 보기 메뉴 활성화 |
| Alt+Page Up, Alt+Page Down | 빌더 호출 편집기의 수직 화면이동 막대를 위/아래로 이동 |
| Ctrl+Alt+Tab | 왼쪽의 테이블을 벗어나 오른쪽의 해당 필드로 이동 |
| Shift+Alt+Page Up, Shift+Alt+Page Down | 빌더 호출 편집기의 수평 화면이동 막대를 왼쪽/오른쪽으로 이동 |
| 아래로 화살표 | 아래 메뉴 옵션으로 탐색 |
| 위로 화살표 | 위 메뉴 옵션으로 탐색 |
| 오른쪽 화살표 | 하위 메뉴 옵션으로 탐색 |
| 왼쪽 화살표 | 하위 메뉴의 메뉴 옵션으로 탐색 |
빌더 호출 편집기가 읽기 어려운 경우 더 큰 글꼴을 사용하거나 낮은 화면 해상도를 사용해 볼 수 있습니다. 여전히 독해도가 충분히 개선되지 않은 경우 빌더 호출 편집기를 자체 창에서 실행할 수 있습니다.
키보드 탐색으로 테이블 내부의 초점을 선택할 수 있습니다. 그러나 빌더 호출 편집기에서 테이블 내부 탐색 및 편집은 보통 테이블 데이터 편집과 다릅니다. 빌더 호출 편집기에서 테이블 셀의 특정 옵션을 선택하면 테이블 외부에서 사용 가능한 입력을 새로 작성할 수 있습니다. 일반적으로 초점이 포함된 셀을 제외하고 첫 번째 새 입력에 초점을 배치하기 위해 사용됩니다. 테이블의 셀에서 첫 번째 새 입력으로 초점을 변경하기 위해 빌더 호출 편집기는 Ctrl+Tab 조합을 지원합니다. 그러면 Tab을 여러 번 눌러서 테이블의 끝까지 탐색하고 마지막 행의 아래로 화살표를 클릭하여 테이블을 종료하고 새 입력을 탐색하는 요구사항이 해제됩니다. 조합은 현재 초점이 포함된 셀에서 선택된 옵션과 관련된 첫 번째 입력으로 초점을 변경합니다.
| 키보드 조합 | 조치 |
|---|---|
| 오른쪽 화살표 | 현재 초점이 셀의 끝에 있는 경우 다음 셀의 시작으로 이동 |
| 왼쪽 화살표 | 현재 초점이 셀의 시작에 있는 경우 이전 셀의 끝으로 이동 |
| 위로 화살표 | 현재 초점이 셀의 첫 행에 있는 경우 위의 셀로 이동 |
| 위로 화살표 | 현재 초점이 테이블의 첫 행에 있는 경우 테이블 종료 |
| 아래로 화살표 | 현재 초점이 셀의 마지막 행에 있는 경우 아래의 셀로 이동 |
| 아래로 화살표 | 현재 초점이 테이블의 마지막 행에 있는 경우 테이블 종료 |
| Tab | 다음 셀로 이동 |
| Tab | 초점이 테이블의 마지막 셀에 있는 경우 테이블에 새 행 추가 및 해당 셀로 이동 |
| Ctrl+Tab | 테이블 외부로 이동 |
| Shift+Tab | 이전 셀로 이동(초점이 첫 번째 셀에 있고 탐색이 없는 경우) |
IBM Support는 IBM Web Experience Factory 제품 결함에 대한 지원을 제공합니다.
IBM Support에 문의하려면 회사에 활성 IBM 소프트웨어 유지보수 계약이 있어야 하며, IBM에 문제점을 제출할 수 있는 권한이 부여되어 있어야 합니다. 사용 가능한 유형의 유지보수 계약에 대한 정보는 다음 위치에 있는 소프트웨어 지원 핸드북의 "지원 포트폴리오"를 참조하십시오.
http://techsupport.services.ibm.com/guides/services.html문제점이 있어 IBM 지원에 문의하려면 다음 단계를 완료하십시오.
Information Center의 검색 질을 개선하기 위한 태스크를 수행해야 할 수 있습니다.
Web Experience Factory Designer를 시작하는 프로시저는 Windows 시스템과 Linux 시스템에서 서로 다릅니다.
제품을 설치하려면 프로그램을 실행하고 몇 가지 질문에 답해야 합니다.
설치가 완료되면 웹 애플리케이션 개발에 사용할 수 있는 여러 확장을 설정할 수 있습니다.
이 안내서를 사용하여 IBM Web Experience Factory 버전 8.0을 설치할 수 있습니다.
이 안내서는 Web Experience Factory에 적용되지만 설치에는 기타 제품 설치가 포함될 수 있습니다.
기본 설치 선택은 지원되는 Eclipse 버전이 포함됩니다. 또는 Web Experience Factory를 다음 IDE 중 하나의 지원되는 버전에 설치할 수도 있습니다.
설치 전에, IBM WebSphere Portal 또는 지원되는 애플리케이션 서버 중 하나를 설치해야 합니다. 애플리케이션 서버 버전 및 패치 레벨은 제품 릴리스 정보 주제의 자세한 시스템 요구사항 섹션을 참조하십시오.
기존에 설치된 Web Experience Factory가 있는 경우 동일한 디렉토리에서 이전 버전 위에 새 버전을 설치하지 마십시오.
신규 설치에 동일한 디렉토리를 사용하려면 다음 단계를 수행하십시오.
그런 다음 Web Experience Factory 제품 설치 안내서에 설명된 단계에 따라 제품 탐색을 시작합니다.
Web Experience Factory를 설치하기 전에 다음을 설치해야 합니다.
Web Experience Factory를 Linux 시스템의 기존 Rational Application Developer 또는 Rational Software Architect 설치에 설치하려면 Web Experience Factory 제품 설치 안내서에 설명된 프로시저를 따르십시오.
config/win_silent_install.properties
config/linux_silent_install.properties
특성 파일에는
설치 프로그램에 대한 기본 응답이 포함됩니다. 자동 설치에 대한 사용자 고유 응답 파일 생성에 대한
정보는 Web Experience Factory 제품 설치 안내서을 참조하십시오. 설치 프로그램은 사용자에게 출력을 표시하지 않고 대상 위치에 모든 것을 설치합니다. 설치 디렉토리의 루트에 로그 파일이 작성될 때 설치가 완료됨을 알게 됩니다.
설치 실행 파일을 실행하고, 원하는 옵션을 선택한 다음 제품을 자동 설치하는 데 사용할 수 있는 텍스트 파일에 이 옵션을 저장할 수 있습니다.
제공된 특성 파일이 아닌 다른 사용자 응답 파일을 사용하여 자동 설치를 실행하려면 Web Experience Factory 제품 설치 안내서의 프로시저를 수행하십시오.
Web Experience Factory Designer를 설치했으면 새 프로젝트를 작성해야 합니다. 프로젝트를 작성할 때 설치에 대한 애플리케이션 서버 특정 및 WebSphere Portal 서버 특정 정보를 제공합니다. 이 프로세스는 Web Experience Factory 설치의 배치 단계를 완료합니다.
Web Experience FactoryDesigner는 프로젝트 작성에 도움이 되는 새로운 프로젝트 마법사를 제공합니다. 이 다중 페이지 마법사는 프로젝트 작성 및 배치에 포함된 단계를 안내하고 프로젝트도 빌드합니다. 프로젝트 설정 및 매개변수를 설명하는 F1 도움말은 마법사의 각 페이지에 사용 가능합니다. 주어진 페이지의 설정에 대해 배우고 추가적 정보에 대한 링크에 액세스하려면 F1 도움말을 참조하십시오.
첫 번째 프로젝트를 작성하는 가장 좋은 방법은 이 프로세스를 설명하는 학습서를 실행하는 것입니다. Windows 클라이언트를 사용하는 경우 이 학습서는 환경 페이지 또는 시작에서 사용할 수 있습니다. 를 클릭하십시오. Linux 클라이언트를 사용하는 경우 이 학습서는 Web Experience Factory 도움말 시스템에서 사용할 수 있습니다.
Web Experience Factory Designer에서는 독일어, 스페인어, 프랑스어, 이탈리아어, 한국어, 일본어, 포르투갈어(브라질), 대만어 및 중국어와 같은 언어를 지원합니다.
영어가 아닌 다른 언어로 Eclipse를 사용하려면 Eclipse 웹 사이트에서 언어 팩을 다운로드하여 해당 팩을 Eclipse IDE에 설치해야 합니다.
Web Experience Factory Designer 새 프로젝트 마법사를 실행한 후에는 Tomcat을 다시 시작하십시오. 이렇게 하면 모든 라이브러리가 올바르게 로드됩니다.
/Factory.bin LAX_VM $JAVA_HOME/bin/java
Web Experience Factory 제품 설치 안내서 또는 Web Experience Factory 제품 설치 안내서(클라이언트 플랫폼에 따라 다름) 및 Web Experience Factory 제품 설치 안내서의 단계에 따라 Web Experience Factory Designer 파일과 프로젝트 WAR 파일을 제거하십시오.
이 절에서는 이전 버전이 설치된 IDE(Eclipse 또는 IBM Rational)에 새 버전의 Web Experience Factory를 설치한 경우 IBM Web Experience Factory 플러그인 파일을 업그레이드하는 데 필요한 프로시저를 설명합니다. 또한 이 절에서는 이전 버전의 Web Experience Factory Designer를 사용하여 빌드된 프로젝트를 최신 프로젝트 버전으로 업데이트하는 방법도 설명합니다. 마지막으로, 이 섹션에서는 포틀릿을 Java Portlet API 표준으로 업그레이드하는 방법을 설명합니다.
'flat' 프로젝트를 업그레이드할 경우 새 프로젝트를 작성하고 기능을 사용하여 컨텐츠를 새 프로젝트로 마이그레이션하십시오. flat 프로젝트는 WebContent 디렉토리가 없는 5.12 또는 6.0 프로젝트입니다. flat 프로젝트를 업그레이드하는 경우 패싯 지원의 추가된 이점을 가져오지 않습니다.
이러한 프로젝트가 새 플러그인 파일 및 기능 세트와 관련된 변경사항을 포함할 수 있도록 이전 플러그인 파일을 사용하여 작성한 프로젝트를 수정해야 합니다.
jar 파일을 /WEB-INF/work/lib에 추가한 경우 프로젝트 업그레이드가 끝나면 빌드 경로에 해당 파일을 수동으로 추가해야 합니다.
WebSphere Portal에는 WebSphere 포틀릿용 Java 포틀릿 표준 API에 대한 지원이 있습니다. 더 이상 사용되지 않는 WebSphere Native 포틀릿 API에서 사용되도록 설계된 포틀릿이 계속 WebSphere Portal에서 실행될 수 있지만, Java 포틀릿 표준 API를 사용하여 새 포틀릿을 빌드하는 것이 좋습니다.
이전 버전의 Web Experience Factory에서 빌드된 포틀릿을 Java 포틀릿 표준 API를 사용하도록 업그레이드하려면 다음 단계를 수행하십시오.
협업 포틀릿 소스 빌더 및 협업 포틀릿 대상 빌더를 사용하는 모델이 있는 경우 프로젝트가 Java Portlet Standard 2.0 API(JSR 286)를 사용하면 모델을 재생성하십시오.
이러한 단계는 이전 버전의 Web Experience Factory에 존재하지 않는 새로운 이벤트 메타데이터를 캡처하기 위해 필요합니다.
이 프로시저는 새 이벤트 메타데이터를 캡처합니다.
IBM Tivoli® License Manager(ITLM)는 시스템에 설치 및 사용된 제품 및 해당 버전, 릴리스와 수정팩을 인식하고 모니터합니다. 이렇게 하면 IBM에서는 설치된 제품의 업데이트 사항을 해당 고객 기반으로 통신하고, 제품 및 사용량에 대해 적합하게 청구할 수 있습니다. 또한 다양한 IBM 소프트웨어 패키지와 번들된 동일한 제품의 다중 설치에 대한 청구를 방지합니다.
IBM Web Experience Factory로 작성된 애플리케이션 및 포틀릿 WAR 파일의 사용을 Tivoli License Manager를 통해 모니터하고 트랙할 수 있습니다. 이 성능을 사용하려면, Web Experience Factory에서 생성한 특정 파일을 애플리케이션 또는 포틀릿 EAR 파일의 루트 레벨에 놓아야 Tivoli License Manager가 인식할 수 있습니다.
Tivoli License Manager 사용 트래킹을 사용하려면 다음 조작을 수행하십시오.
Web Experience Factory를 설치하고 내게 필요한 옵션으로 JAWS 화면 판독기를 사용하려면 다음 추가 단계를 수행하여 올바로 설치를 시작해야 합니다.
IBM Lotus Expeditor(XPD) 6.1.1이 동적 JSP를 지원할 수 있도록 하려면 웹 변환기 기능을 사용하십시오.
IBM Lotus Expeditor(XPD) 6.1.1을 설치하여 웹 변환기 기능을 통해 동적 JSP를 지원하도록 설정하십시오.
IBM Web Experience Factory에서는 몇 가지 백엔드 시스템을 통합할 수 있습니다.
기타 기능 세트를 추가하면서 해당 프로젝트에 통합 확장을 추가할 수 있습니다. 그러면 확장에 제공된 빌더를 사용할 수 있습니다.
그러나 필수 설치, 구성 및 관련된 주제 시작하기에 설명된 설정 단계를 수행해야 확장을 사용할 수 있습니다.
이 주제에서는 Lotus Collaboration 확장에 대해 설명합니다.
이 패키지는 IBM Lotus Domino 컴포넌트 및 서비스에 Domino 빌더를 제공하여 Web Experience Factory의 성능과 유연성을 확장합니다.
이 기능 세트에는 Domino 에이전트의 원격 호출 및 실행과 추가 보안 스키마(예: LTPA 토큰 또는 IBM WebSphere Portal Server 신임) 사용을 지원하는 기능도 포함되어 있습니다. 포틀릿 사용자에 대해 싱글 사인온을 둘 다 사용하십시오.
이 패키지로 작성한 포틀릿 및 위젯은 기타 Lotus 협업 서비스(예: 대화, 이메일, 프로파일 발견, 작성자 및 문서 검색)를 이용하도록 인식을 통합할 수도 있습니다. 그리고 Web Experience Factory의 고유 기능을 사용하여 포틀릿 및 위젯을 사용자 정의하면, 사용자에게 필요한 보기 및 협업 기능만 제공하는 사용자 정의 포틀릿 또는 위젯을 작성할 수 있습니다.
기타 모든 기능 세트의 경우와 마찬가지로 Collaboration 패키지를 설치하십시오.
편의를 위해 Domino 서버 설정을 확립하고 제어하는 특성 파일을 설정할 수 있습니다. Domino 데이터 액세스 빌더에서 이 파일을 선택하면 이는 Domino 서버에 연결을 설정하는 데 사용됩니다.
이 파일은 프로젝트 WEB-INF/config/domino_config 디렉토리에 있습니다. 특성 파일은 기본 Domino 연결 특성(예: Domino 서버 이름 및 올바른 Domino 사용자 이름과 비밀번호)를 지정하는 데 사용됩니다. 일반적인 Domino 특성 파일에는 domino.properties란 이름이 지정되고 다음이 들어 있을 수 있습니다.
# Domino application server
ServerName=
# Domino User Name
UserName=
# Domino Password
PassWord=
# Domino server http port
# The http port is used when the builder is configured to retrieve rich rext items as HTML.
# The Domino Attachment builder also uses these values when creating http
# links to attachments in the documents.
DominoHttpPort=80
# SSL Settings
# When rich text items are fetched as HTML, relative urls to Domino resources (images,
# other documents, etc.) in the html are converted to absolute URLS to the Domino
# resource. Thus, the browser will request these resources using the absolute URL.
# If the absolute URLS to Domino resources should use https, set DominoConvertAbsUrlsToSSL
# to true. Also set DominoHttpsPort to your Domino server's https port.
# The Domino Attachment builder will also use these properties when forming
# the URL to the attachment.
DominoConvertAbsUrlsToSSL=true
DominoHttpsPort=443
# If the application on the application server should use https when fetching rich text
# items from Domino's web server, set the following property to true.
# Note: if this property is true, the certificate from Domino's web server will need
# to be added to your application server JVM's cacerts file.
DominoUseHttps=false
이 패키지 및 이에 포함된 빌더를 사용하려면 Domino 서버에 대한 IIOP(Internet Inter-Orb Protocol) 액세스가 있어야 합니다. 추가 정보는 Domino 도움말을 참조하십시오.
인식 기능을 활성화하려면 IBM WebSphere Portal Server 확장 또는 WebSphere Portal Experience 제품을 실행 중이어야 하고, 이런 제품의 협업 컴포넌트가 Domino 서버에 올바로 구성되어 실행 중이어야 합니다. 이런 컴포넌트에는 Sametime®(대화용), Discovery(사용자 프로파일 표시, 작성자/문서 검색 및 메일용) 중 하나 이상이 포함됩니다.
이 제품의 릴리스 정보를 점검하여 이 패키지에서 컴포넌트를 지원하는 Lotus Collaboration 제품을 표시할 수 있습니다.
Domino데이터 액세스 빌더가 Domino 자원에 액세스하기 위해서는 Domino 서버 보안이 원격 호출을 적절히 허용 및 제한하도록 구성되어야 합니다. 이 액세스를 통제하는 구성 설정은 Domino Administrator에서 설정됩니다.
현재 서버 문서의 보안 탭을 확인하여 보안 설정을 검토할 수 있습니다. 이런 설정 확립에 대한 자세한 정보는 Domino Designer 도움말을 참조하십시오. Domino 버전 6에서는 Domino Designer 도움말 항목인 을 참조하십시오. 서버 요구사항 섹션에서 보안 설정을 설명합니다.
Domino 서버는 빌더의 다양한 컨트롤이 사용 가능한 데이터베이스, 보기, 양식 및 에이전트의 목록으로 채워질 수 있도록 데이터베이스 찾아보기를 지원해야 합니다. 데이터베이스를 검색 가능하게 하는 Domino 서버 설정은 Domino 디렉토리의 서버 문서 탭에 있습니다. 또한 보안 탭을 열고 익명 주 연결 허용을 사용 가능(예)으로 설정하십시오.
Domino 에이전트를 포틀릿 또는 위젯에서 원격으로 호출하여 실행하려면 에이전트를 서명해야 합니다. 사용자 엔터프라이즈 보안 정책에서 이를 수행하는 방법을 지시하겠지만 최종 결과는 포틀릿 또는 위젯 사용자가 포틀릿 또는 위젯 내에서 원격으로 에이전트를 호출할 수 있는 권한을 갖는 것이어야 합니다.
SSL에 제공된 보안을 이용하려면 Web Experience Factory 및 Domino가 SSL 조작에 대해 올바로 구성되도록 일부 프로시저를 수행하십시오. 다음 단계는 Domino 연결에 SSL을 사용하는 데 필요합니다.
bowstreet.domino.session.enableSSL=true
TrustedCerts.class 파일은 DIIOP 포트가 SSL에 사용 가능한 경우 Domino 서버에 의해 생성됩니다. 이 파일에는 서버가 검증한 인증이 포함되어 있습니다.
install_directory\Designer\eclipse\plugins\com.bowstreet.designer.core_version-number\lib
Bundle-ClassPath: designercore.jar,
lib/jakarta-poi.jar,
lib/jxl.jar,
lib/sapjco.jar,
lib/SiebelJI.jar,
lib/SiebelJI_Common.jar,
lib/SiebelJI_enu.jar,
lib/Siebel.jar,
lib/sslClasses.jar
lib/activation.jar,
lib/portlet.jar,
lib/bstres.jar,
lib/bstres_nl1.jar,
lib/builderui-res.jar,
lib/builderui-res_nl1.jar,
lib/jdom.jar,
lib/builderimages.jar,
lib/NCSO.jar,
lib/packman.jar,
lib/factory.jar,
lib/builderui.jar,
lib/j2ee.jar,
lib/icons.jar,
lib/wsdl4j.jar,
lib/classparser.jar,
lib/axis.jar,
lib/commons-fileupload.jar,
lib/commons-logging.jar,
lib/commons-discovery.jar,
lib/commons-pool.jar,
lib/wc50.jar,
lib/WidgetExtension.jar,
lib/WidgetExtension_nl1.jar,
lib/xercesImpl.jar,
lib/xml-apis.jar,
bin/,
lib/log4j.jar
Eclipse 버전 3.2.x 및 그 아래 버전의 경우
다음 위치에 있는 plugin.xml 파일을 편집하여
이 jar 파일을 포함시키십시오.install_directory\WEFDesigner\eclipse\plugins\com.bowstreet.designer.core_version-number
예를 들어, 다음과 같습니다.
<library name="lib/sslClasses.jar">
<export name="*"/>
</library>
이를 추가하면 TrustedCerts.class 파일을 런타임 환경에서 사용할 수 있습니다.
domino_server.my_company.com:63148
Domino 포틀릿 빌드를 시작하는 데는 두 가지 방법이 있습니다.
다음의 단순한 단계에 따라 사용자 정의 Domino 포틀릿을 빌드하십시오.
포틀릿이 구성되지 않았습니다.
포틀릿의 구성 아이콘을 사용하여 포틀릿을 구성하십시오. Domino 서버, 데이터베이스 및 보기 외에 기타 Domino 구성 설정도 지정해야 합니다.
포틀릿 구성 및 WebSphere 포털에서 포틀릿 보기에 대한 자세한 정보를 표시하려면 포틀릿의 도움말 단추를 클릭하십시오.
Domino 샘플에 액세스하여 제품 위키에서 관련 기사를 조사하십시오.
Domino 샘플에 액세스하여 제품 위키에서 관련 기사를 조사하십시오.
NCSO.jar에 있는 이전의 호환 가능한 Domino 8 버전이 Web Experience Factory에 패키지되었습니다. 이는 Domino CORBA 구현 시에 성능을 향상시킵니다.
이 주제에서는 PeopleSoft 확장에 대해 설명합니다.
PeopleSoft 확장은 IBM Web Experience Factory 사용자에게 다음과 같은 중요 기능을 전달합니다.
기타 모든 기능 세트의 경우와 마찬가지로 PeopleSoft 확장을 설치하십시오.
PeopleSoft Java 오브젝트 어댑터 JAR 파일, psjoa.jar는 PeopleSoft 설치 또는 PeopleSoft 고객 서비스 담당자로부터 얻을 수 있습니다.
JAR 파일에는 PeopleSoft 서버에 액세스하기 위해 빌더가 사용하는 Java 클래스가 포함되어 있습니다. PeopleSoft를 로컬로 설치한 경우 PS_HOME 디렉토리에서 이 파일의 사본이 있는지 찾아보십시오.
빌더 및 JAR 파일이 올바로 설치되었는지 확인하려면 다음 단계를 수행하십시오.
PeopleSoft 빌더 사용의 첫 번째 단계는 특성 파일을 설정하는 것입니다. 이 파일은 프로젝트 /WEB-INF/config/peoplesoft_config/ 디렉토리에 있습니다. 특성 파일(default_connection.properties)은 연결 특성(예: PeopleSoft 서버의 이름, 올바른 PeopleSoft 사용자 이름 및 비밀번호)을 지정하는 데 사용됩니다.
일반적인 특성 파일에는 다음 특성이 포함될 수 있습니다.
#Default connection properties for the PeopleSoft Builders
# PeopleSoft application server
hostserver=pplsoft:9000
# Logon user name
UserName=jdoe
# Logon password
PassWord=PS
PeopleSoft 빌더는 백엔드 PeolpeSoft 서버에 대한 세션 풀링을 지원합니다. 기본적으로, 세션 풀링은 사용하지 않습니다(Web Experience Factory Designer 환경에 합당한 구성). 그러나 서버의 경우 풀링을 통해 작성하는 세션 수를 최소화하고 전반적인 빌더 런타임 성능을 향상시키려고 할 수 있습니다.
아래 표의 특성을 PeopleSoft 프로젝트 .../WEB-INF/config/override.properties 파일에 추가하여 PeopleSoft 세션 풀링을 사용 및 구성할 수 있습니다.
| 특성 | 기본값 | 효과 |
|---|---|---|
| bowstreet.peoplesoft.session.pool.enabled | false | 정의되고 TRUE로 설정되면 세션 풀링이 사용 가능합니다. |
| bowstreet.peoplesoft.session.pool.maxActiveSessions | 8 | 동시의 최대 활성 세션 수. 음수인 경우, 활성 세션 수에 제한이 없습니다. |
| bowstreet.peoplesoft.session.pool.maxIdleSessions | 8 | 동시에 풀에 있는 유휴 세션의 최대수. 음수인 경우, 유휴 세션 수에 제한이 없습니다. |
| bowstreet.peoplesoft.session.pool.maxWait | -1 | 세션이 풀로 리턴되는 것을 대기하는 최대 시간(밀리초 단위). 음수인 경우, 요청 중인 스레드는 세션이 리턴되는 것을 무제한 대기합니다. 지정된 시간에 풀로 리턴된 세션이 없는 경우, 요청 중인 스레드는 예외를 수신합니다. |
| bowstreet.peoplesoft.session.pool.maxIdleTimeSeconds | 1800 | 세션이 축출 및 재승인되기 전에 풀에서 유휴 상태에 있도록 허용되는 최대 시간(초 단위). 음수인 경우, 세션이 유휴 시간에 기초하여 축출되지 않습니다. |
| bowstreet.peoplesoft.session.pool.idleSessionSweepSeconds | 30 | 풀에서 축출 및 재승인할 유휴 세션을 찾는 스윕 간의 최대 시간(초 단위). 음수인 경우, 풀 스위핑을 사용하지 않습니다. |
| bowstreet.peoplesoft.session.pool.maxAgeMinutes | -1 | 유휴 세션 설정과 상관없이 세션이 축출 및 재승인되기 전
세션의 최대 수명(분 단위). 음수인 경우, 세션은 해당 수명으로 인해 절대 축출 및 재승인되지
않습니다. 참고: 이는 공통 라이브러리에 구현되지 않은 Web Experience
Factory 특정 기능/특성입니다.
|
이 주제에서는 SAP 확장에 대해 설명합니다.
SAP 확장은 IBM Web Experience Factory 사용자에게 다음과 같은 중요 기능을 제공합니다.
SAP Extension의 컴포넌트에서는 다음 SAP 제품 버전을 지원합니다.
| SAP 제품 | 지원되는 버전 |
|---|---|
| R3 | 지원되는 버전은 Web Experience Factory 릴리스 정보 주제의 자세한 시스템 요구사항을 참조하십시오. |
SAP 확장 설치
또한 sapjco3.dll 파일을 Windows 운영 체제의 system32 디렉토리로 복사하십시오. (예를 들어, Windows XP 시스템의 경우 C:\Windows\system32.)
그룹, 아티팩트, 버전 및 유형의 값은 대부분 임시입니다. 이름 지정 규칙이나 기타 모든 고려사항에 대응하는 값을 선택하십시오. 설치를 클릭하면 JAR 파일이 WASCE/repository/그룹/아티팩트/버전/유형 디렉토리에 위치하게 되며 WebSphere Application Server Community Edition 서버 전체 클래스 로더에 의해 로드됩니다.
-rwxr-xr-x (755)
소유자는 root이고 그룹은
Web Experience
Factory 사용자가 속한 그룹으로 설정되어야 합니다.
Web Experience
Factory 사용자가
WebSphere Application Server 사용자와 다른 경우
해당 사용자가 SAP 라이브러리에 액세스할 수 있게 하려면 SAP
Java Connector 설치 문서에 지시된 대로
해당 사용자의 환경을 설정해야 합니다. C:\Program Files\IBM\Web Experience Factory\Designer\eclipse\plugins\com.bowstreet.designer.core_latest version
/home/user/IBM/Designer/eclipse/plugins/com.bowstreet.designer.core_latest version
<?xml version="1.0" encoding="UTF-8"?>
<web-app>
<dependency>
<groupId>wef_integration</groupId>
<artifactId>WEF_JCo3Common.jar</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>wef_integration</groupId>
<artifactId>sapjco3.jar</artifactId>
<version>3.0.5</version>
</dependency>
</web-app>
빌더 및 JCo가 올바로 설치되었는지 확인하려면 다음 단계를 따르십시오.
SAP 빌더 사용의 첫 번째 단계는 대상 특성 파일을 설정하는 것입니다. 이 파일은 프로젝트 WEB-INF/config/sap_config/ 디렉토리에 있습니다.
특성 파일은 SAP 연결 특성(예: SAP 서버 이름 및 올바른 SAP 사용자 이름과 비밀번호)을 지정하는 데 사용됩니다. 일반적인 SAP 특성 파일에는 my_sap.properties란 이름이 지정되고 다음 특성이 포함되어 있을 수 있습니다.
# SAP application server
jco.client.ashost=
# Logon user
jco.client.user=
# Logon password
jco.client.passwd=
# SAP client
jco.client.client=000
# Logon language
jco.client.lang=EN
# SAP system number
jco.client.sysnr=00
기본 SAP server.properties 파일이 SAP 빌더와 함께 설치되며 WEB-INF/config/sap_config 디렉토리에 있습니다. 파일을 사용하여 기본 SAP 설정을 확립하고 올바른 특성 값의 예를 볼 수 있습니다. 설치 시 구성된 대로 이 파일은 로컬 호스트에서 실행 중인 MiniSAP 서버에 적용 가능합니다.
SAP Extension을 설치 및 구성한 후 오브젝트 브라우저 모델을 실행하십시오. 이 모델을 사용하여 SAP 시스템의 오브젝트를 탐색할 수 있습니다. 다음 단계를 사용하십시오.
SAP 빌더는 SAP JCo 인터페이스(SAP 시스템과 함께 사용 가능)을 사용하여 SAP에 연결합니다. 이 인터페이스를 통해 Java 애플리케이션이 SAP 시스템과 통신할 수 있습니다. SAP JCo 인터페이스는 연결 풀링을 지원하고 포틀릿과 SAP 간 통신의 관리를 감독합니다.
JCo 인터페이스는 대상 풀링을 사용하고 구성하는 데 사용되는 몇몇 새 특성을 정의합니다. 클라이언트 퍼스펙티브에서 대상은 SAP 서버와의 통신을 설정하기 위해 JCo 인터페이스에서 사용되는 연결 특성 세트입니다. 이러한 풀링 특성은 WEB-INF/config/SAP_config/. 아래에 저장된 특성 파일에 추가될 수 있습니다.
jco.destination.peak_limit=5
jco.destination.pool_capacity=1
jco.destination.expiration_time=60000
최대 한계는 대상에 대해 한 번에 활성일 수 있는 최대 연결 수를 정의합니다. 풀 용량은 대상 풀에서 유지될 유휴 연결 수를 정의합니다. 값이 0이면 풀링 사용을 사용할 수 없습니다. 만기 시간(밀리초로 지정됨)은 유휴 연결이 끊어지고 제거되기 전에 대상 연결 풀에 머무는 최대 시간을 정의합니다.
최대 한계의 기본값 5가 적절한 연결 수와 좋은 성능을 제공합니다.
이 절은 Web Experience Factory를 사용하여 구현되고 SAP에 액세스하는 배치된 WAR과 관련이 있습니다. 혼합 환경이 있는 경우에는 Web Experience Factory에서 작성하지 않은 Web Experience Factory 및 WAR이 JCo 인터페이스를 통해 SAP에 액세스하고 구성을 조정할 수 있도록 약간의 사용자 정의 코드를 작성해야 합니다.
Web Experience Factory를 사용하여 SAP에 액세스하는 모든 배치된 WAR을 구현하는 경우 이 절의 내용을 무시하십시오.
SAP JCo 인터페이스는 클라이언트가 서버에 액세스하는 방법을 정의하기 위해 대상의 개념을 사용합니다. 클라이언트 퍼스펙티브에서 대상은 JCo 인터페이스가 특성에 지정된 서버에 연결하기 위해 사용하는 이름 지정된 연결 특성 세트입니다. 이러한 연결은 클라이언트에 노출되지 않으므로 모든 클라이언트는 JCo 메소드에 대상 이름을 전달하여 SAP 서버와 통신해야 합니다.
Web Experience Factory는 대상 데이터 제공자라고도 하는 레지스트리를 구현하며 이 레지스트리는 대상 특성 세트를 관리할 책임이 있습니다. 이 레지스트리는 각 특성 세트에 고유한 대상 이름을 지정한 다음 클라이언트가 JCo 메소드에서 대상 이름을 참조할 때 JCo에 적합한 특성 세트를 제공합니다.
JCo 인터페이스를 사용하여 JCo 런타임에 대해 단 하나의 대상 데이터 제공자만을 구성할 수 있습니다. JCo 인터페이스를 통해 SAP에 액세스하는 모든 WAR은 동일한 대상 데이터 제공자를 사용해야 합니다. 대상 데이터 제공자 레지스트리는 WEF_JCo3Common.jar 파일에 있습니다. 이 JAR을 애플리케이션 서버가 공유 JAR 파일을 로드하는 디렉토리에 배치하면 Web Experience Factory 대상 데이터 제공자 구현이 Web Experience Factory를 사용하여 빌드되었는지 여부에 관계 없이 모든 WAR에서 이 구현을 사용할 수 있습니다. SAP에 액세스하는 모든 WAR이 Web Experience Factory로 빌드된 경우에는 추가 단계가 필요하지 않습니다.
com.bowstreet.builders.webapp.methods.JCo3Common.DestinationRegistry
bowstreet.sap.destinationRegistry
런타임 시 WAR의 SAP 빌더가 이 클래스의 단일 인스턴스를 인스턴스화하고 해당 단일 인스턴스를 사용하여 모든 필수 대상을 등록합니다.
JCo 인터페이스에서는 여러 스레드를 포함하는 단일 트랜잭션의 일부로 다중 SAP 함수 호출을 지원하기 위해 세션 참조 제공자를 사용하여 세션 ID를 생성합니다. Web Experience Factory는 세션 참조 제공자를 SAP 빌더 런타임의 일부로서 구현 및 사용합니다. JCo 인터페이스는 JCo 런타임에 적합하게 구성될 때 하나의 세션 참조 제공자만 사용합니다. JCo 인터페이스를 통해 SAP에 액세스하는 모든 WAR은 동일한 세션 참조 제공자를 사용해야 합니다.
Web Experience Factory 세션 참조 제공자는 WEF_JCo3Common.jar 파일에 들어 있습니다. 이 파일을 애플리케이션 서버가 공유 JAR을 로드하는 디렉토리에 배치하면 Web Experience Factory를 사용하여 빌드되었는지 여부에 관계 없이 모든 WAR에서 Web Experience Factory 제공자 구현을 사용할 수 있습니다. SAP에 액세스하는 모든 WAR이 Web Experience Factory를 사용하여 빌드된 경우 추가 단계가 필요하지 않습니다.
com.bowstreet.builders.webapp.methods.JCo3Common.SessionProvider
이
인터페이스를 사용하여 Web Experience
Factory는
SAP 빌더가 수행하는 트랜잭션의 시작 및 끝을
구별합니다. Web Experience
Factory는
다음 특성을 SessionProvider 인터페이스를
구현하는 클래스의 완전한 이름으로 설정하여 써드파티
제공자를 사용하도록 구성되어 있습니다. bowstreet.sap.sessionProvider
런타임 시
WAR의 SAP 빌더가 이 클래스의 단일 인스턴스를 인스턴스화하고
해당 단일 인스턴스를 사용하여 모든 트랜잭션을 구별합니다. 이 주제에서는 Siebel 확장에 대해 설명합니다.
Siebel 확장은 IBM Web Experience Factory 사용자에게 다음과 같은 기능을 제공합니다.
Siebel 확장의 컴포넌트는 다음 Siebel 제품 버전을 지원합니다.
| Siebel 제품 | 지원되는 버전 |
|---|---|
| Siebel CRM 솔루션 | 지원되는 버전은 Web Experience Factory 릴리스 정보 주제에 언급된 자세한 시스템 요구사항을 참조하십시오. |
Siebel 확장은 Siebel Java Data Bean 인터페이스를 활용하여 Siebel 저장소에 액세스합니다. 결과적으로, 다음과 같은 버전 특정 Siebel JAR 파일을 Siebel 시스템 관리자로부터 확보해야 합니다.
기타 모든 기능 세트의 경우와 마찬가지로 Siebel 확장을 설치하십시오.
C:\IBM\WEF\WEFDesigner\eclipse\plugins\com.bowstreet.designer.core_x.y.z
Meta-Inf 폴더는 JAR 파일을 배치한 \lib 폴더와 동일한 플러그인 폴더에 있습니다.
manifest 파일의 기본 정의가 충분해야 합니다. 그러나 서버에서 사용하기 위해 가져온 Siebel JAR 파일의 이름이 다르게 지정된 경우에는 Web Experience Factory Designer가 해당 JAR 파일을 로드할 수 있도록 정의를 조정하십시오.
Siebel jar 파일을 IBM WebSphere Application Server Community Edition(CE) 서버에 추가하십시오.
Web Experience Factory에서 프로젝트의 geromino-web.xml 파일을 업데이트하십시오.
<dependency>
<groupId>wef_integration</groupId>
<artifactId>SiebelJI_enu</artifactId>
<version>7.8</version>
</dependency>
<dependency>
<groupId>wef_integration</groupId>
<artifactId>siebel</artifactId>
<version>7.8</version>
</dependency>
/WebSphere/AppServer/lib/ext
파일 인코딩을 일치시켜야 합니다. 제대로 통신하려면 Siebel 서버와 외부 Siebel 클라이언트(예: Web Experience Factory)가 호환 가능한 파일 인코딩을 사용해야 합니다. 예를 들어, 기본 Windows 파일 인코딩은 Cp1252입니다. RedHat Linux의 경우, 기본 파일 인코딩은 UTF-8입니다.
Siebel 빌더를 제대로 사용하려면 클라이언트 플랫폼이 Siebel 서버에서 사용하는 파일 인코딩과 일치하는지 확인하십시오. 예를 들어, Web Experience Factory Designer가 Linux 시스템에서 실행되는 경우, JVM에 대한 기본 파일 인코딩이 Siebel 서버에서 사용하는 기본 파일 인코딩과 다를 수 있습니다. Siebel의 경우, Sieibel 서버에 연결하기 위해 Java API를 사용하는 클라이언트에 Siebel 서버에 있는 것과 동일한 기본 파일 인코딩이 있어야 합니다. **기본 파일 인코딩 설정이 다르면 Could not open a session in 4 attempts 메시지가 재생성되는 중에 Siebel Coordinator가 실패합니다. 이로 인해 모델 오류가 발생하여 모델이 실행되지 않습니다.
-Dfile.encoding=utf8
Eclipse 및 Web Experience
Factory Designer를
다시 시작하면 클라이언트 기본 인코딩이 서버와 동일한 값으로 설정되고 Siebel 빌더가
올바르게 재생성됩니다.WebContent\factory\util\testSiebelConnection.jsp 파일을 사용하여 Siebel 연결을 테스트할 수 있습니다. 다음 단계를 수행하여 연결 특성이 올바른지 확인하십시오.
http://yourserver:port/projectName/factory/util/testSiebelConnection.jsp
Siebel 빌더 사용의 첫 번째 단계는 특성 파일을 설정하는 것입니다. 이 파일은 프로젝트 WEB-INF/config/siebel_config/ 디렉토리에 있습니다. 특성 파일(default_connection.properties)은 연결 특성(예: Siebel 서버에 대한 연결 문자열 및 올바른 Siebel 사용자 이름과 비밀번호)을 지정하는 데 사용됩니다.
일반적인 특성 파일에는 다음 특성이 포함됩니다.
#Default connection properties for the Siebel Builder
ConnectString=siebel://10.10.2.125:2320/siebel_es/SSEObjMgr_enu/wicdemo9
UserName=sadmin
Password=sadmin
Siebel default_connection.properties 파일은 Siebel 빌더와 함께 설치됩니다. 이 특성 파일은 WEB-INF/config/siebel_config/ 디렉토리에 있습니다. 파일을 사용하여 기본 Siebel 설정을 확립하고 올바른 특성 값의 예를 볼 수 있습니다. 설치 시 구성된 대로 이 파일은 로컬 호스트에서 실행 중인 Siebel 서버에 적용 가능합니다.
RepositoryName=Siebel Repository
Siebel
Repository를 활성 저장소의 이름으로 바꾸십시오. Siebel 빌더는 백엔드 Siebel 서버에 대한 세션의 풀링을 지원합니다. 기본적으로, 세션 풀링은 사용하지 않습니다(Web Experience Factory Designer 환경에 합당한 구성). 그러나 서버에서는 풀링을 사용해 작성되는 세션 수를 최소화하여 전반적인 빌더 런타임 성능을 향상시킬 수 있습니다.
아래 표의 특성을 Siebel 프로젝트 .../WEB-INF/config/override.properties 파일에 추가하여 Siebel 세션 풀링을 사용 및 구성할 수 있습니다.
| 특성 | 기본값 | 효과 |
|---|---|---|
| bowstreet.siebel.session.pool.enabled | false | 정의되고 TRUE로 설정되면, 세션 풀링이 사용 가능합니다. |
| bowstreet.siebel.session.pool.maxActiveSessions | 8 | 동시의 최대 활성 세션 수. 음수인 경우, 활성 세션 수에 제한이 없습니다. |
| bowstreet.siebel.session.pool.maxIdleSessions | 8 | 동시에 풀에 있는 유휴 세션의 최대수. 값이 음수인 경우, 유휴 세션 수에 제한이 없습니다. |
| bowstreet.siebel.session.pool.maxWait | -1 | 세션이 풀로 리턴되는 것을 대기하는
최대 시간(밀리초 단위). 음수인 경우, 요청 중인 스레드는 세션이 리턴되는 것을 무제한 대기합니다. 지정된 시간에 풀로 리턴된 세션이 없는 경우, 요청 중인 스레드는 예외를 수신합니다. |
| bowstreet.siebel.session.pool.maxIdleTimeSeconds | 1800 | 세션이 축출 및 재승인되기 전에 풀에서 유휴 상태에 있도록
허용되는 최대 시간(초 단위). 음수인 경우, 세션이 유휴 시간에 기초하여 축출되지 않습니다. |
| bowstreet.siebel.session.pool.idleSessionSweepSeconds | 30 | 풀에서 축출 및 재승인할 유휴 세션을 찾는 스윕 간의
최대 시간(초 단위). 음수인 경우, 풀 스위핑을 사용하지 않습니다. |
| bowstreet.siebel.session.pool.maxAgeMinutes | -1 | 유휴 세션 설정과 상관없이 세션이 축출 및 재승인되기 전
세션의 최대 수명(분 단위). 값이 음수인 경우 세션은 해당 수명으로 인해 절대 축출 및 재승인되지 않습니다. 참고: 이는 공통 라이브러리에 구현되지 않은
Web Experience
Factory 고유의
기능/특성입니다.
|
작업 환경의 여러 측면을 구성할 수 있습니다.
Web Experience Factory 구성에 대한 자세한 정보를 보려면 이 위키 링크(http://www-10.lotus.com/ldd/pfwiki.nsf/xpViewRecent.xsp?searchValue=configure%2C%20configuring)를 클릭하십시오.
다음 단계에 따라 Web Experience Factory Designer 환경 설정을 변경하십시오.
Web Experience Factory 환경 설정 대화 상자를 표시할 수 있습니다.
다음 단계에 따라 Web Experience Factory Designer 기본 환경 설정을 복원하십시오.
Web Experience Factory Designer에서 다양한 환경 설정을 설정할 수 있습니다.
이 환경 설정은 Web Experience Factory Designer 편집 환경의 기능 및 모양과 더불어 모델을 실행할 때 사용할 서버 런타임 자원의 기능 및 모양을 판별합니다.
Web Experience Factory Designer 기본 환경 설정의 세트는 Web Experience Factory Designer preferences.ini 파일에 저장됩니다. 이 파일은 eclipse\plugins\com.bowstreet.designer.ui 디렉토리에 있습니다. 기본 환경 설정을 변경할 경우 사용자 정의된 환경 설정 세트는 작업공간에 저장되므로 기본 환경 설정을 겹쳐쓰지 않습니다. 이 스토리지 전략을 사용하여 언제라도 기본 환경 설정을 복원할 수 있습니다.
이 주제에서는 변경할 수 있는 Web Experience Factory Designer 편집 환경 설정에 대해 설명합니다.
를 클릭하면 다음 설정을 사용할 수 있습니다.
| 설정 | 설명 |
|---|---|
| 브라우저 명령 | 모델 실행 시
시작할 웹 브라우저의 경로를 입력하십시오. 참고: 이 설정을 변경하면
기존 실행 구성이 아니라 새 실행 구성만 적용됩니다.
|
| 특성 파일 위치 대체 | override.properties
파일을 저장할 경로를 지정하려면 이 설정을 사용하십시오.
이 파일은 프로젝트를 작성할 때 WEB-INF/config
디렉토리에 작성됩니다. 이 파일의 설정은 제공된
특성 파일에 설정되어 있는 기본 특성 설정을 바꾸고 로그 위치를
판별하는 데도 사용됩니다. 참고: 이 필드 값의 변경사항은 Web Experience
Factory Designer를
다시 시작할 때까지 적용되지 않습니다.
|
| IBM Support Assistant 위치 | IBM Support Assistant가 설치되어 있는 경우 이를 실행하는 데 사용되는 경로를 지정하십시오. |
| 숨겨진 오브젝트 표시 | 빌더 호출을 통해
웹 애플리케이션에 추가된 모든 오브젝트를 표시하도록 모델 편집기의
애플리케이션 트리 패널을 설정합니다. 빌더 호출 편집기에서 적용을
클릭하면 숨겨진 모든 오브젝트가 표시됩니다. 일반적으로
숨겨진 오브젝트를 볼 필요가 없습니다. 참고: 개발자가 숨기도록
지정한 변수, 메소드, LJO 및 기타 오브젝트는 숨겨진
오브젝트 표시 선택란의 상태에 관계 없이 참조 선택기에
표시되지 않습니다.
|
| 보기 데이터 랩 | 여러 메소드
및 페이지 도메인 뷰어의 긴 텍스트 행을 그 다음 실제
행에 표시합니다. 애플리케이션 트리 패널과 연관된 뷰어에는 웹 애플리케이션 오브젝트의 컨텐츠(예: 페이지 또는 메소드)가 표시됩니다. 경우에 따라 이 정보를 한 줄에 표시하는 것이 유용합니다. 다른 경우 정보를 랩된 텍스트로 표시하는 것이 좋습니다. |
| 빌더를 열 때 보기 펼치기 | 빌더를 열 때 보기를 펼칩니다. |
| 새 프로젝트에 기본 폴더 작성 | 새 Web Experience Factory 프로젝트를 작성할 때마다 사용할 수 있도록 프로젝트 작성 마법사에서 기본 폴더 작성 옵션을 설정합니다. |
| 빌더 호출 편집기 페이지에 적용 단추 표시 | 적용 단추를 사용할 수 있도록 설정합니다. 적용을 클릭하면 편집 내용이 저장되고 재생성이 시작되며 빌더 호출 편집기는 열린 상태로 유지됩니다. 적용 단추가 없는 경우 변경사항을 저장하려면 확인을 클릭해야 합니다. 빌더 호출 편집기는 닫힙니다. |
| 두 빌더 유형을 모두 표시하는 기본 빌더 선택도구 | 일반적으로 빌더 선택도구는 모델 편집기 컨텍스트에 따라 사용자 인터페이스 또는 데이터 제공자 빌더를 사용 가능한 것으로 표시합니다. 컨텍스트에 관계 없이 두 가지 유형 모두 표시하려면 빌더 선택도구에서 이 설정을 둘 다로 설정하십시오. |
| 그룹 아웃라인 기준 | 보기 메뉴 그룹 기준 명령을 사용하여 아웃라인 보기에 빌더를 나열하는 기본 제어를 설정합니다. 현재 아웃라인 보기를 설정과 일치하도록 변경하려면 적용을 클릭하십시오. 끌어서 놓기는 번호순으로 정렬된 경우에만 사용할 수 있습니다. |
| 빌더 호출 편집기 | 빌더 호출
편집기의 표시 유형을 선택합니다.
참고: 이 설정의 변경사항은 환경 설정이 저장된 후 열린 모델에 적용됩니다. 이 설정을 열린 모델에 적용하려면,
모델을 닫고 다시 열어야 합니다.
|
Web Experience Factory 특성은 일부 개발 측면에 영향을 줍니다.
다음과 같은 모델 개발 측면이 Web Experience Factory 특성에 의해 판별됩니다. 달리 지정되어 있지 않는 한 WEB-INF/config/cluster.properties 파일에 모든 특성이 표시되어 있습니다.
# specifies the compiler to use
bowstreet.methods.compiler=C:/jdk131/bin/javac.exe
# This is where the generated source(.java) will go
bowstreet.methods.sourceDirectory=${bowstreet.rootDirectory}/work/source
# This is where the compiled class will go. This should be in a place where the dynamic class loader can pick it up.
bowstreet.methods.targetDirectory=${bowstreet.rootDirectory}/work/classes
#In bowstreet.properties file
# classpath-like syntax (semi-colon delimited) for location of BuilderDef files
# default if unavailable is ${bowstreet.rootDirectory}/builders
bowstreet.location.builderdef.path=${bowstreet.rootDirectory}/builders
동적으로 클래스를 로드할 위치를 여러 개 지정하려면 다음 예제처럼 각 경로를 쉼표로 구분하여 특성에서 추가 경로를 추가하십시오.
#In bowstreet.properties file
bowstreet.dynamic.class.load.path=${bowstreet.rootDirectory}/work/classes,${bowstreet.rootDirectory}/work/my_classes
bowstreet.dynamic.class.load.checkTimestamp=true
bowstreet.dynamic.class.load.checkTimestamp 특성을 true로 설정한 경우 동적 클래스 로더에서 로드할 클래스에 대해 시간 검사를 수행합니다. 특성을 true로 설정된 상태에서 클래스가 변경되면 클래스가 로더 클래스 경로에 있으며 동적으로 로드되는 지원 클래스 중 하나인 경우 다음 인스턴스 작성 시 클래스는 동적으로 다시 로드됩니다.
# Uncomment these parameters to add 1999 and/or 2000/11 XMLSchema References into
# SOAP responses when using pre-Factory 5.9 SOAPPC and SOAPDOC URLs (not used by Axis)
#bowstreet.soap.schemaRef.1999=true
#bowstreet.soap.schemaRef.2000=true
예를 들면 다음과 같습니다.
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:gcdXmlResponse xmlns:ns1="http://bowstreet.com/2002/03/models/xmethods/gcd">
<gcdreply><distance>2708.88</distance></gcdreply>
</ns1:gcdXmlResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Web Experience Factory가 특성과 함께 SOAP 인코딩 스키마를 검색하는 위치를 지정할 수 있으며, 기본적으로 bowstreet.location.schemas로 설정됩니다.
Web Experience Factory 5.9에서는 서비스 호출 빌더의 고급 입력 섹션에서 추가 서비스 단위 호출 프록시 설정을 사용할 수 있습니다.
bowstreet.schema.maxCacheSize= 특성을 사용하여 최대 스키마 캐시 크기를 제어할 수 있습니다. 최대 캐시 크기의 기본값은 50개의 스키마 오브젝트입니다.
두 개의 대체 특성 파일은 다른 특성 파일에 설정된 특성 설정의 위치를 가져오는 데 사용할 수 있습니다.
대체 기능은 bowstreet.properties 또는 cluster.properties의 일반적인 로깅 설정과 같은 다른 특성 파일의 설정을 바꿀 때 유용합니다. 제공된 특성 파일의 설정을 변경하는 경우 제품을 업그레이드하면 변경사항이 유실됩니다.
IBM Web Experience Factory Designer는 override.properties 파일을 사용하여 IBM 서버 config 디렉토리에 지정된 대체 특성은 물론 Web Experience Factory Designer에 대한 로깅 특성을 지정합니다.
대체 특성 파일은 다음과 같습니다.
designer_core_version_number/config
개발 중인 특성을 변경하면 이 환경 설정을 사용하여 변경사항이 프로젝트 전체와 IBM 시스템 전체에 제대로 전파됩니다.
Web Experience Factory Designer가 시작할 때마다 다음 조치가 발생합니다.
Designer Install Location/plugins/com.bowstreet.designer.core_x.y.z/config/override.properties
logging.driver.eventSink.directory=eclipseinstalldir
/workspace/.metadata/.plugins/com.bowstreet.designer.core/logs
logging.driver.eventSink.prefix=designer_event_logging.event.flush.interval=1
그러면 Web Experience Factory Designer 로그는 적절한 위치에 기록됩니다. override.properties의 모든 기타 특성은 적용되지 않습니다.
애플리케이션 빌드 시 사용되는 Java 런타임 환경(JRE)의 버전을 구성할 수 있습니다.
Build path specifies execution environment J2SE-1.5.
There are no JREs installed in the workspace that
are strictly compatible with this environment.
이 경고는
Web Experience
Factory Designer가 Java 6 JRE
이전 버전에서 실행되기 때문에 생성됩니다. Web Experience
Factory Designer는
설치된 JRE를 Web Experience
Factory
Designer가 실행되는 버전인 Java 6 JRE에만 적합하게
구성했습니다. (Web Experience
Factory Designer에 알려진 JRE는 이 버전 뿐입니다.)
기본적으로 Web Experience Factory 프로젝트 설정에서 프로젝트에 Java 5 런타임 환경이 필요한 것으로 지정합니다. Web Experience Factory Designer는 적합한 대상 매개변수를 사용해서 프로젝트에서 Java 코드를 컴파일하여 생성된 Java .class 파일이 Java 5 JRE에서 실행될 수 있도록 합니다. 그러나 Java 코드에서 새로 작성되고 Java 6에만 존재하는 API를 참조하는 경우 여전히 런타임 문제가 발생할 수 있습니다. Java 6 클래스 라이브러리는 프로젝트의 컴파일 클래스 경로에 있으므로 Java .class 파일을 생성하는 데 사용됩니다. 이러한 상황으로 인해 올바른 버전 플래그가 지정된 Java .class 파일이 Java 5 JRE에서 실행될 수 있는 것으로 표시되지만 Java 6 JRE에서만 사용 가능한 API가 필요합니다.
이 경고 메시지를 제거하려면 다음 프로시저 중 하나를 수행하십시오.
Eclipse 콘솔 창에 디버그 정보를 전송하는 것은 유용합니다.
콘솔에 리턴된 정보는 모델 및 애플리케이션에 대한 문제점을 해결하는 데 도움이 될 수 있습니다.
Web Experience Factory Designer의 콘솔 창을 표시하려면 다음 단계를 수행하십시오.
이러한 플래그는 생성 중에 발생하는 디버그 명령문을 모두 전송할 콘솔 창을 표시합니다.
IBM Web Experience Factory 개발 및 런타임 환경을 구성하는 데 수행할 수 있는 태스크에는 여러 가지가 있습니다.
IBM Web Experience Factory가 실행하는 애플리케이션 및 Web Experience Factory Designer에 대해 모두 명령 콘솔을 사용할 수 있습니다. 명령 콘솔을 사용하여 코드에 사용된 System.out.println() 문을 볼 수 있습니다. 빌더 Java 클래스에 있는 모든 System.out.println() 문이 Web Experience Factory Designer 콘솔에 표시됩니다. 모델에서 링크된 Java 오브젝트(LJO) 또는 메소드에 대한 모든 System.out.println() 명령문은 Application Server의 콘솔에 표시됩니다.
개발 중인 웹 애플리케이션에서 기존 JAR 파일을 사용할 수 있습니다.
설계 시 액세스해야 하는 API를 포함할 수 있습니다(예: 사용자 정의 빌더를 사용하여). 또는 빌더 생성 또는 빌더 코디네이터 클래스에서 참조해야 하는 JAR(예: 제3의 소프트웨어로부터)를 가질 수 있습니다.
특성을 설정하여 동적 클래스 로딩을 구성할 수 있습니다.
동적 클래스 로딩이 사용 가능합니다. Web Experience Factory 서블릿이 서비스 호출을 처리할 때마다, 클래스 파일 시간소인을 검사합니다. 나중에 시간소인이 존재하는 경우 새 클래스 버전이 로드됩니다. 일반적으로 성능상의 이유로 checkTimestamp 특성은 개발 환경에서 true로 설정되고 프로덕션 환경에서는 false로 설정됩니다.
IBM Web Experience Factory 서블릿을 구성하여 링크된 Java 오브젝트, 프로파일 세트 관리자 및 재생성 클래스를 동적으로 로드할 수 있습니다.
정상 조작 모드에서 classpath의 클래스 파일은 애플리케이션 서버가 시작될 때마다 JVM의 기본 ClassLoader에 의해 로드됩니다. 그러나 애플리케이션 서버가 실행 중일 때 클래스 파일이 변경되면(예: Java 파일을 다시 컴파일하는 경우), 기본 ClassLoader는 클래스를 다시 로드하지 않습니다.
개발 환경에서 클래스를 더 자주 다시 로드할 수 있습니다. 그러나 클래스 파일을 변경할 때마다 애플리케이션 서버를 다시 시작할 필요가 없습니다. 이 경우 동적 클래스 로딩이 유용할 수 있습니다.
동적 클래스 로딩이 사용 가능할 때 성능 비용을 초래한다는 점에 주목하십시오. 동적 클래스 로딩이 사용 가능한 경우, 모델이 서비스 또는 링크된 오브젝트 클래스에 대해 작성한 각 호출에 대해 클래스 파일 시간소인이 선택됩니다. 이 경우, 개발 환경에서만 동적 클래스 로딩을 사용 가능하게 하고 개발 또는 프로덕션 환경에서는 사용 안함으로 하는 것이 좋습니다.
애플리케이션 서버를 다시 시작할 필요 없이 Java 클래스 파일을 동적으로 로드하도록 Web Experience Factory 서블릿을 구성할 수 있습니다. 개발 Web Experience Factory 서블릿을 공유하고 서비스에 사용된 Java 클래스를 자주 업데이트하는 경우 이 작업을 수행해야 합니다.
bowstreet.dynamic.class.load.path 특성에 지정된 디렉토리에서 Java 클래스가 동적으로 로드됩니다.
bowstreet.dynamic.class.load.path 특성의 기본값은 프로젝트의 IBM Web Experience Factory WEB-INF/work/classes 및 WEB-INF/work/lib 디렉토리에 있습니다.
다음 디렉토리는 Web Experience Factory 프로젝트에 있는 Java 클래스 및 JAR 파일의 스토리지와 웹 아카이브(WAR) 파일 시스템용으로 사용됩니다.
Web Experience Factory 동적 클래스 로더는 WEB-INF/work/classes 및 WEB-INF/work/lib 폴더에서 클래스를 로드합니다.
서버측에서 Web Experience Factory 동적 클래스 로더는 J2EE WAR 클래스 로더에 로딩을 위임합니다. 이 클래스 로더는 WAR 파일의 WEB-INF/classes 및 WEB-INF/lib 폴더에서 클래스를 로드하고 Application Server의 클래스 로더에 로딩을 위임합니다.
Web Experience Factory Designer 측에서 Web Experience Factory 동적 클래스 로더는 Web Experience Factory WAR 클래스 로더에 로딩을 위임합니다. 각 Web Experience Factory 프로젝트는 현재 프로젝트의 Eclipse Java 빌드 경로를 기반으로 클래스를 로드하는 고유한 Designer WAR 클래스 로더를 갖습니다. Designer WAR 클래스 로더는 프로젝트의 WEB-INF/work/classes 또는 WEB-INF/work/lib 폴더 아래 있는 항목을 제외한 Eclipse Java 빌드 경로의 항목을 모두 사용합니다. Designer WAR 클래스 로더는 Eclipse 클래스 로더에 로딩을 위임합니다.
로딩을 위임하면 Web Experience Factory 프로젝트는 서버에 있는 것과 같은 방식으로 Designer에서 작동합니다.
프로젝트 WEB-INF/work/source/ 트리에 있는 Java 소스 코드가 컴파일된 후 출력이 프로젝트 WEB-INF/work/classes 트리에 저장됩니다. 이 디렉토리의 컨텐츠는 동적으로 로드되어 변경사항을 적용하기 위해 Web Experience Factory Designer 또는 서버를 다시 시작할 필요가 없습니다. 따라서 모든 Java 소스 변경사항은 WEB-INF/work/classes에서 즉시 확인할 수 있습니다. 이 배치는 소스 코드가 자주 변경되는 개발에 도움이 됩니다.
JAR 파일에 관한 한, WEB-INF/work/lib 디렉토리는 WEB-INF/work/classes 디렉토리와 기능적으로 같습니다.
WEB-INF\config\override.properties 파일에서 다음 특성을 false로 설정하여 동적 클래스 로딩을 사용 안함으로 할 수 있습니다.
bowstreet.dynamic.class.load.checkTimestamp
IDE(Integrated Development Environment)에서 Java 코드로 오브젝트에 대한 Javadoc에 액세스할 수 있습니다.
IBM Web Experience Factory Designer는 Eclipse 기반 개발 환경으로 모두 통합되었습니다.
Web Experience Factory Designer는 다음 Eclipsed 기반 통합 개발 환경(IDE)에 대한 플러그인입니다.
아래 테이블은 Web Experience Factory 프로젝트의 특성을 설명합니다.
| 프로젝트 특성 | 설명 |
|---|---|
| 프로젝트 속성 | Web Experience Factory 프로젝트에서 Java 프로젝트 속성을 사용합니다. |
| 프로젝트 컨텐츠 | Web Experience Factory 프로젝트에는 Web Experience Factory에서 제공 가능한 컨텐츠 루트 디렉토리의 모든 컨텐츠가 들어 있습니다. 예를 들어 wpf.war 및 아래 항목과 같습니다. |
| 소스 디렉토리 | Web Experience Factory 프로젝트는 Web Experience Factory 설치의 WEB-INF/work/source 디렉토리를 소스 디렉토리로 사용합니다. 소스 디렉토리로 다른 디렉토리를 지정할 수 있지만 이 디렉토리는 반드시 포함해야 합니다. |
| 빌드 디렉토리 | 프로젝트 Java 소스 파일이 컴파일된 WEB-INF/temp 디렉토리를 가르킵니다. Web Experience Factory Designer 플러그인의 파트로 포함된 Ant 스크립트는 이 디렉토리의 클래스를 WEB-INF/work/classes 디렉토리로 복사합니다. |
| 포함된 라이브러리 | Web Experience Factory 프로젝트는 Web Experience Factory WEB-INF/lib 디렉토리에 모든 JAR 파일을 포함하고 WEB-INF/clientlibs/servlet.jar에 JAR 파일을 포함합니다. |
| 외부 도구 | Ant 스크립트 사본 클래스는 컴파일된 Java WEB-INF/work/classes 디렉토리를 복사합니다. |
다음 디렉토리에서 Web Experience Factory Designer에 대한 로그 파일을 찾을 수 있습니다.
eclipse/plugins/com.bowstreet.designer.core/log
Web Experience Factory WEB-INF/logs 디렉토리에서 Web Experience Factory에 대한 로그 파일을 찾을 수 있습니다.
도움말의 표시 방법을 구성하려면 다음 단계를 수행하십시오.
현재 수정팩에 대해 알리도록 IBM 지원 센터 사이트를 구성할 수 있습니다.
이 태스크를 수행하려면 IBM ID 및 비밀번호가 필요합니다. 이 프로시저 중에 등록하여 ID 및 비밀번호를 작성할 수 있습니다. 수정팩 알림을 이미 구독하고 있는 경우에는 현재 구독을 보고 관리할 수 있습니다.
다른 JRE 버전 또는 벤더로 변경하려는 경우, 다음 단계를 수행해야 합니다.
웹 애플리케이션 개발을 지원하기 위해 여러 개의 샘플이 제공됩니다.
http://www-10.lotus.com/ldd/pfwiki.nsf
위키 시작 페이지의 빠른 링크 표제 아래에 있는
샘플을 클릭하십시오. 샘플에 대한 기사가 제목을 기준으로
알파벳 순으로 나열되어 있으며 카테고리(예: 데이터 액세스 및 서비스)별로 액세스할 수 있습니다. 이 링크(http://www-10.lotus.com/ldd/pfwiki.nsf/xpViewCategories.xsp?lookupName=Media%20Gallery)를 클릭하면 여러 기능, 개념 및 "방법"에 대한 비디오 데모를 볼 수 있습니다.
아래에 나열된 주제는 Web Experience Factory 환경에서 웹 애플리케이션을 개발 및 작성하는 방법에 대한 자세한 정보를 다룹니다.
이 빠른 시작 안내서는 WAS CE(WebSphere Application Server Community Edition)를 사용하여 프로젝트를 작성하고 애플리케이션을 실행하는 방법을 단계별로 설명합니다.
WebSphere Application Server CE를 사용하면 애플리케이션을 빠르고 쉽게 개발 및 테스트할 수 있습니다. IBM Web Experience Factory를 설치할 때 WebSphere Application Server CE를 설치할 수 있습니다.
WAS CE(WebSphere Application Server Community Edition)는 Apache Geronimo 기반의 개방형 소스 J2EE(Java 2 Platform, Enterprise Edition) Application Server입니다.
다음 단계에 따라 WebSphere Application Server CE와 함께 사용할 기본 프로젝트를 작성하십시오.
다음 단계에 따라 WebSphere Application Server CE 프로젝트 작성에서 작성한 WebSphere Application Server CE 프로젝트 파일을 사용하여 샘플 애플리케이션을 실행하십시오. 서버에서 샘플 애플리케이션을 실행하여 모두 올바르게 구성되었는지 테스트합니다.
models\samples\gettingstarted\OrdersServiceConsumer
모두 올바로 구성되었으면 브라우저에 웹 애플리케이션이 표시됩니다. 이 애플리케이션에 대해 아무 작업도 할 필요가 없습니다. 단순히 브라우저에서 설정이 올바르게 표시되는지, WebSphere Application Server가 해당 애플리케이션을 실행 중인지 확인하십시오.
IBM Web Experience Factory의 여러 강력한 기능을 소개하는 네 개의 학습서 중 첫 번째 학습서입니다.
이 학습서에서는 WebSphere Portal용 Web Experience Factory 프로젝트 작성 방법을 학습합니다. WebSphere Application Server Community Edition(WAS CE)용 프로젝트 작성 방법을 다루는 학습서는 IBM WebSphere Application Server CE에서 IBM Web Experience Factory를 사용하기 위한 빠른 시작을 참조하십시오.
이 학습서 세트는 신규 Web Experience Factory 개발자에게 유용합니다. 이 학습서의 네 파트를 완료하는 데 각각 30 - 45분이 걸립니다. 각 학습서는 이전 학습서에서 얻은 지식을 토대로 진행되므로, 다음 순서에 따라 완료해야 합니다. 또한 Web Experience Factory에 대해 보다 자세히 학습하려면 해당 학습서를 완료한 후 Web Experience Factory 위키에서 Web Experience Factory 학습 로드맵을 방문하십시오.
| 학습서 순서 | 설명 |
|---|---|
웹 애플리케이션 프로젝트
작성 |
이 학습서에서는 웹 애플리케이션 프로젝트 작성 방법을 학습합니다. |
| 애플리케이션 작성 | 이 학습서에서는 간단한 "hello world" 애플리케이션을 빌드한 후 해당 애플리케이션에서 포틀릿을 작성합니다. |
| 데이터베이스 애플리케이션 작성 | 이 학습서에서는 샘플 데이터베이스에 대해 SQL 테이블 작성 빌더를 사용하여 서비스 제공자 모델을 작성한 다음 서비스 이용자 빌더 및 데이터 서비스 사용자 인터페이스를 사용하여 사용자 인터페이스 서비스 이용자 모델을 작성합니다. |
| 새 애플리케이션에서 프로파일링 사용 | "hello world" 애플리케이션 학습서에 이어서 애플리케이션에 프로파일링 기능을 추가합니다. |
IBM Web Experience Factory 설치 후, 포틀릿 작성의 첫 단계는 Web Experience Factory Designer를 사용하여 Web Experience Factory 프로젝트를 작성하는 것입니다. 이 프로젝트는 포틀릿 또는 애플리케이션의 기초가 되며, 이들을 공개하는 데 필요한 모든 아티팩트를 포함합니다.
이 학습서에서는 Web Experience Factory 프로젝트를 작성하고, IBM WebSphere Portal 환경에서 사용할 수 있도록 구성하며, 샘플을 실행하여 설정이 올바른지 확인합니다. 이러한 태스크가 완료되면, 다른 학습서를 완료하여 Web Experience Factory를 사용한 웹 애플리케이션 및 포틀릿 개발에 대한 기본사항을 배울 수 있습니다.
다음은 학습서를 실행하기 위해 필요한 설정입니다.
하나의 서버 구성만 작성하면 됩니다. 이 서버 구성은 개발 중 프로젝트를 테스트하기 위해 두 애플리케이션 서버 모두에 프로젝트를 공개하고 WebSphere Portal에서 볼 수 있도록 WebSphere Portal에 포틀릿을 공개합니다.
개발자가 설정할 수 있는 많은 다른 구성이 있습니다. 가장 일반적인 구성 유형은 다음과 같습니다.
| 구성 유형 | 설명 |
|---|---|
| 로컬로 설치된 WebSphere Portal 및 애플리케이션 서버 | WebSphere Portal
Server 및 임베드 WebSphere Application Server가
로컬로 설치되었습니다.
새 서버 구성을 작성할 때 애플리케이션 서버 installedApps
폴더와 같은 중요한 폴더는 로컬
하드 드라이브를 가리킵니다. 이 구성은 사용하기 매우 쉽지만 적합한 레벨의 성능을 달성하려면 최소 2GB의 RAM을 갖춘 강력한 개발 시스템이 필요합니다. |
| 원격으로 설치된 WebSphere Portal 및 애플리케이션 서버 | WebSphere Portal Server 및 임베드 WebSphere Application Server는 네트워크에서 액세스할 수 있는 다른 시스템에 설치됩니다. |
사용 환경에 대한 구성을 완료하려면 온라인 도움말을 참조하십시오.
문제가 있는 경우 /WEB-INF/logs 디렉토리에 있는 서버 구성 관련 공개 로그를 확인하십시오.
Web Experience Factory 6.x의 로컬 설치를 사용 중인 경우 기본적으로 WebSphere Application Server의 보안이 사용됩니다. 따라서 배치 WAR 파일이 작성되는 동안 신임을 묻는 메시지가 표시될 수도 있습니다. WebSphere Portal 관리자 신임이 아닌 WebSphere Application Server 관리자 신임을 사용하십시오. 또한 실행되지 않은 공개 프로세스를 종료하기 전에 이 프롬프트를 기다려야 합니다. 프롬프트를 무시하면 제한시간 초과되어 WAR 파일이 자동으로 공개되지 않습니다. 이 경우에도 WebSphere 관리 콘솔을 사용하여 WAR 파일을 수동으로 설치하고 구성할 수 있습니다.
이제 Web Experience Factory 프로젝트를 작성했으므로 서버에서 샘플 애플리케이션을 실행하여 모두 올바로 구성되었는지 테스트합니다.
축하합니다! Web Experience Factory 프로젝트를 성공적으로 작성했으며 샘플 애플리케이션을 실행하여 구성을 확인했습니다. 작성된 Web Experience Factory 프로젝트에는 사용자가 작성한 모든 모델과 Web Experience Factory 웹 애플리케이션 및 포틀릿을 개발, 공개 및 테스트하는 데 필요한 모든 지원 코드 및 아티팩트가 들어 있습니다.
이제 다음 단계인 Web Experience Factory Designer를 사용하여 웹 애플리케이션 및 포틀릿을 개발하는 방법을 배울 준비가 되었습니다. 애플리케이션 작성 학습서를 시작하십시오.
IBM Web Experience Factory의 여러 강력한 기능을 소개하는 네 개의 학습서 중 두 번째 학습서입니다.
이 학습서에서는 간단한 "hello world" 애플리케이션을 빌드합니다.
이 학습서 세트는 새 Web Experience Factory 개발자에게 유용한 시작점입니다. 이 학습서의 네 파트를 완료하는 데 각각 30 - 45분이 걸립니다. 각 학습서는 이전 학습서에서 얻은 지식을 토대로 진행되므로, 다음 순서에 따라 완료해야 합니다. 또한 Web Experience Factory에 대해 보다 자세히 학습하려면 해당 학습서를 완료한 후 Web Experience Factory 위키에서 Web Experience Factory 학습 로드맵을 방문하십시오.
| 학습서 순서 | 설명 |
|---|---|
웹 애플리케이션 프로젝트
작성 |
이 학습서에서는 웹 애플리케이션 프로젝트 작성 방법을 학습합니다. |
애플리케이션
작성 |
이 학습서에서는 간단한 "hello world" 애플리케이션을 빌드한 후 해당 애플리케이션에서 포틀릿을 작성합니다. |
| 데이터베이스 애플리케이션 작성 | 이 학습서에서는 샘플 데이터베이스에 대해 SQL 테이블 작성 빌더를 사용하여 서비스 제공자 모델을 작성한 다음 서비스 이용자 빌더 및 데이터 서비스 사용자 인터페이스를 사용하여 사용자 인터페이스 서비스 이용자 모델을 작성합니다. |
| 새 애플리케이션에서 프로파일링 사용 | "hello world" 애플리케이션 학습서에 이어서 애플리케이션에 프로파일링 기능을 추가합니다. |
개발자가 모델을 작성하고, 이 모델에 빌더를 추가하고, 방금 작성한 애플리케이션을 실행한 다음 해당 애플리케이션에서 포틀릿을 작성하는 방식으로 애플리케이션을 작성합니다.
다음은 학습서를 실행하기 위해 필요한 설정입니다.
새 애플리케이션을 작성하려는 경우, 새 모델을 작성한 다음 알맞은 빌더 호출을 모델에 추가합니다.
빌더에는 사용하기 쉬우며 마법사와 비슷한 사용자 인터페이스가 있어서 애플리케이션을 빠르고 쉽게 개발할 수 있습니다. 그러나 빌더는 전체 개발 프로세스를 통해 반복적으로 사용될 수 있으므로 마법사보다 훨씬 강력합니다. 일회 실행 마법사를 제공하는 다른 IDE와 달리, Web Experience Factory에서는 언제든지 돌아가서 빌더의 입력 값을 변경할 수 있고 전체 애플리케이션을 즉시 업데이트할 수 있습니다.
실제로 빌더는 알맞은 자동화 태스크(예: 단추에 대한 JSP 작성)를 수행하는 Java 클래스 및 빌더의 입력 및 설계 시 사용자 인터페이스 특성을 정의하는 XML 문서(빌더 정의)로 구성됩니다.
애플리케이션 트리가 표시되지 않은 경우 MyFirstPortlet 모델이 열리거나 선택되었는지 확인하십시오. 그러한 경우 프로젝트 탐색기 창의 MyFirstPortlet 모델을 찾아서 두 번 클릭하십시오.
애플리케이션 트리의 여러 요소를 선택하도록 하고 소스 및 설계 보기에서 강조 표시된 해당 요소를 감시합니다.
을 클릭하여 이 모델에 추가할 수 있는
빌더 목록을 표시하십시오. 사용 가능한 모든 빌더 및
해당 빌더 카테고리가 이 목록에 표시됩니다.
여러 빌더가 페이지를 수정할 수 있으므로 여러 선택사항이 표시됩니다.현재 애플리케이션을 작성하기는 했지만 모델이 포틀릿으로 사용되도록 설정하지는 않았습니다. 이제 모델이 WebSphere Portal 프레임워크 내에서 포틀릿으로 실행되도록 설정합니다. 이러한 용도로 사용되는 포틀릿 어댑터 빌더가 있으므로 이 태스크는 쉽게 완료할 수 있습니다.
프로파일링은 고급 학습서에서 다루며, 여기서는 구성 및 편집 페이지의 기본 사용자 인터페이스(UI)가 매우 단순하다는 점을 다룹니다. 이러한 페이지에 대한 더 풍부한 UI는 각 HTML 페이지 또는 Web Experience Factory 모델에서 별도로 작성할 수 있습니다. 이러한 페이지 및 모델은 포틀릿 어댑터 빌더 호출에서 참조할 수 있으며 빌더는 이들을 자동으로 포틀릿이 추가합니다.
포틀릿 어댑터 빌더 호출을 MyFirstPortlet 모델에 추가한 다음 포틀릿을 포털 페이지에 추가하여 작업을 테스트하십시오.
을 클릭하여
모델에 새 빌더 호출을 추가하십시오. 아직 선택하지 않았으면 모두 카테고리를 선택하십시오.| 입력 이름 | 주어진 입력에 이 값을 입력 |
|---|---|
| 이름 | tutorial_basics |
| 포틀릿 제목 | 학습서 기본 – 포틀릿 |
| 포틀릿 설명 | 핵심 개념을 설명하는 단순 예제 |
그러나 모델에 대한 내용을 일부 변경하려면 포틀릿 WAR을 다시 공개해야 합니다. 모델에 포틀릿 어댑터 빌더를 추가하는 것이 해당 변경사항 중 하나입니다. 포털 프레임워크가 새 포틀릿을 인식하도록 하려면 포털 서버의 포틀릿 WAR을 새 것으로 바꾸어야 합니다. Web Experience Factory Designer에서 기존 포틀릿 WAR을 다시 공개하면 새 WAR이 자동으로 기존의 것을 대신하여 공개됩니다.
Web Experience Factory는 포틀릿 및 J2EE 준수 웹 애플리케이션 개발을 위한 강력한 도구입니다. 애플리케이션 및 포틀릿은 빌더에서 작성됩니다. 모델의 각 빌더 호출은 Web Experience Factory가 생성하는 것으로 간주되는 애플리케이션의 XML 표현에 영향을 미칩니다. 재생성 프로세스를 통해 애플리케이션이 작성됩니다.
이제 SQL 데이터 서비스 빌더를 사용하여 샘플 데이터베이스에 대한 서비스 제공자 모델을 작성한 다음 서비스 이용자 및 데이터 서비스 UI 빌더를 사용하여 사용자 인터페이스 서비스 이용자 모델을 작성하는 학습서 - 데이터베이스 애플리케이션 작성 학습서를 수행할 준비가 되었습니다.
"hello world" 애플리케이션 학습서에 이어서 애플리케이션에 프로파일링 기능을 추가합니다.
이 학습서 세트는 신규 Web Experience Factory 개발자에게 유용합니다. 이 학습서의 네 파트를 완료하는 데 각각 30 - 45분이 걸립니다. 각 학습서는 이전 학습서에서 얻은 지식을 토대로 진행되므로, 다음 순서에 따라 완료해야 합니다. 또한 Web Experience Factory에 대해 보다 자세히 학습하려면 해당 학습서를 완료한 후 Web Experience Factory 위키에서 Web Experience Factory 학습 로드맵을 방문하십시오.
| 학습서 순서 | 설명 |
|---|---|
웹 애플리케이션 프로젝트
작성 |
이 학습서에서는 웹 애플리케이션 프로젝트 작성 방법을 학습합니다. |
애플리케이션
작성 |
이 학습서에서는 간단한 "hello world" 애플리케이션을 빌드한 후 해당 애플리케이션에서 포틀릿을 작성합니다. |
데이터베이스
애플리케이션 작성 |
이 학습서에서는 샘플 데이터베이스에 대해 SQL 테이블 작성 빌더를 사용하여 서비스 제공자 모델을 작성한 다음 서비스 이용자 빌더 및 데이터 서비스 사용자 인터페이스를 사용하여 사용자 인터페이스 서비스 이용자 모델을 작성합니다. |
새 애플리케이션에서
프로파일링 사용 |
"hello world" 애플리케이션 학습서에 이어서 애플리케이션에 프로파일링 기능을 추가합니다. |
이 학습서에서는 애플리케이션에 프로파일링을 추가합니다. 프로파일링하면 애플리케이션의 다양한 파트에 대해 대체 값 세트를 공급하여 Web Experience Factory가 애플리케이션의 여러 버전을 동적으로 빌드할 수 있습니다.
Web Experience Factory의 가장 강력한 면 중 하나는 모델을 프로파일링이라는 개념과 함께 사용하여, 동일한 코드 기반에 대해 사전 정의된 여러 매개변수 세트를 조합하여 동일한 애플리케이션의 여러 버전을 생성하는 것입니다. 이 학습서 파트에서는 빌더 입력 세트에 대한 새 프로파일 세트를 작성합니다. 프로파일 세트에는 프로파일된 빌더 입력에 대한 두 가지 다른 값의 세트가 들어 있습니다. 두 세트의 값에 따라 애플리케이션은 다른 방식으로 작동합니다. 완료하면 스위치를 반전하거나 모델을 다시 실행하여 호출할 수 있는 두 버전의 애플리케이션이 생성됩니다.
을 클릭하여 이 빌더 입력 사용을 프로파일하십시오.설계 보기 및 애플리케이션 트리 보기에서 애플리케이션의 두 변형을 볼 수 있습니다. 두 프로파일 사이에 전환할 때 적용 단추를 클릭하면 애플리케이션에서 변경사항을 볼 수 있습니다. 예를 들어, 로 웹 애플리케이션 트리를 펼치는 경우 page1을 클릭하십시오. 오른쪽에 해당 컨텐츠가 정적 텍스트, 파일 이름 및 JSP scriptlet과 표현식으로 바뀐 몇몇 <div> 태그가 표시됩니다.
이 단계에서는 이미지 빌더를 추가하고 프로파일링을 사용하여 이 빌더를 사용하는지 사용하지 않는지 판별합니다. 사용하지 않는 빌더는 생성된 애플리케이션에 아무런 영향도 미치지 않습니다. 빌더의 사용/사용 안함 값을 프로파일 항목에 연관시키면 빌더는 재생성 시 적용된 프로파일에 따라서만 재생성되어 자동으로 추가되거나 삭제됩니다.
| 입력 이름 | 주어진 입력에 이 값을 입력 |
|---|---|
| 위치 기술 | 이름 지정된 태그에 상대적 |
| 페이지 | page1 |
| 태그 | namedTag |
| 배치 | 이후 |
| 새 태그 이름 | imgTag |
| 이미지 소스 | 필더의 오른쪽에서 을 클릭하여 참조 선택기를 실행하십시오. 파일 선택 탭을
클릭하고 /samples/tutorials/images/tutorial_basics_image.jpg를 선택한 다음
확인을 클릭하십시오. |
을 클릭하여 이 빌더 입력 사용을 프로파일하십시오.
다른 프로파일 항목과 마찬가지로 항목 작성을
사용하고 프롬프트를 표시 이미지로 변경한 후 UI 유형을
"선택란"으로 설정하고 선택란 이후 레이블 필드를 내 선택란으로 편집하십시오.
확인을 클릭하십시오. 포털에서 사용자 정의(사용할 프로파일 구성) 시 프로파일 항목의 UI 유형이 표시됩니다. 모델의 일부 빌더 호출 입력을 프로파일링하면 단순히 프로파일을 전환함으로써 여러 버전의 애플리케이션을 생성할 수 있습니다. Web Experience Factory Designer의 적용된 프로파일 탭에서 프로파일을 선택할 수 있습니다. 포틀릿 어댑터 빌더 호출 구성 방법에 따라 포틀릿 관리자 및 사용자는 포틀릿의 구성 및 편집 모드를 사용하여 WebSphere Portal에서 다양한 프로파일을 적용할 수 있습니다. 또한 프로파일 선택 처리라는 프로세스를 통해 프로그램적으로 프로파일을 선택할 수도 있습니다.
프로파일은 자국어 지원 및 포털 그룹에 대한 프로파일링에 사용할 수도 있습니다. 자세한 정보는 다음 위키 기사를 참조하십시오.
이 학습서에서는 SQL 테이블 작성 빌더를 사용하여 샘플 데이터베이스에 대한 서비스 제공자 모델을 작성합니다.
SQL 테이블 작성 빌더는 데이터베이스 테이블을 작성하고 서비스 조작으로 공개된 전체 CRUD(작성, 검색, 업데이트 및 삭제) 기능을 제공합니다. 학습자는 서비스 이용자 및 데이터 서비스 UI 빌더를 사용하여 사용자 인터페이스 서비스 이용자 모델을 작성합니다.
이 학습서 세트는 신규 Web Experience Factory 개발자에게 유용합니다. 이 학습서의 네 파트 대부분을 완료하는 데 30 - 45분이 걸리지만 이 학습서에 1시간 - 1시간 30분의 시간을 할애해야 합니다. 각 학습서는 이전 학습서에서 얻은 지식을 토대로 진행되므로, 다음 순서에 따라 완료해야 합니다. 또한 Web Experience Factory에 대해 보다 자세히 학습하려면 해당 학습서를 완료한 후 Web Experience Factory 위키에서 Web Experience Factory 학습 로드맵을 방문하십시오.
| 학습서 순서 | 설명 |
|---|---|
웹 애플리케이션 프로젝트
작성 |
이 학습서에서는 웹 애플리케이션 프로젝트 작성 방법을 학습합니다. |
애플리케이션
작성 |
이 학습서에서는 간단한 "hello world" 애플리케이션을 빌드한 후 해당 애플리케이션에서 포틀릿을 작성합니다. |
데이터베이스
애플리케이션 작성 |
이 학습서에서는 샘플 데이터베이스에 대해 SQL 테이블 작성 빌더를 사용하여 서비스 제공자 모델을 작성한 다음 서비스 이용자 빌더 및 데이터 서비스 사용자 인터페이스를 사용하여 사용자 인터페이스 서비스 이용자 모델을 작성합니다. |
| 새 애플리케이션에서 프로파일링 사용 | "hello world" 애플리케이션 학습서에 이어서 애플리케이션에 프로파일링 기능을 추가합니다. |
SQL 테이블 작성 빌더를 사용하여 샘플 데이터베이스에 대한 서비스 제공자 모델을 작성한 다음 서비스 이용자 및 데이터 서비스 사용자 인터페이스 빌더를 사용하여 사용자 인터페이스 서비스 이용자 모델을 작성합니다. 제공자 모델은 테이블 작성 빌더를 사용하여 XML 파일에 제공된 샘플 데이터에서 데이터베이스 테이블을 작성한 다음 해당 모델이 서비스 제공자로 전환되는 서비스 조작을 생성합니다. 이용자/제공자 패러다임 및 데이터 서비스 사용자 인터페이스 사용법을 비롯하여 이 학습서에서 익힌 내용을 통해 다른 데이터 제공자(예: IBM Lotus Domino)를 사용할 때 필요한 지식을 얻을 수 있습니다.
다음은 학습서를 실행하기 위해 필요한 설정입니다.
을 클릭하여 이 모델에
추가할 수 있는 빌더 목록을 표시하십시오. 
서비스 제공자 빌드 단계를 완료했습니다! 다음 단계에서는 이 제공자와 함께 작동할 서비스 이용자를 작성하고 사용합니다.
을 클릭하여 이 모델에
추가할 수 있는 빌더 목록을 표시하십시오.
을 클릭하여 이 모델에
추가할 수 있는 빌더 목록을 표시하십시오. 
페이지 링크, 단추, 작성 단추가 있으며, 데이터베이스 테이블의 처음 5개 행을 표시하는 생성된 웹 사용자 인터페이스가 표시되어야 합니다. 애플리케이션 사용, 행을 통한 페이징, 업데이트, 레코드 작성 및 삭제를 수행해 보십시오. 마지막 단계에서 작성한 빌더 호출의 결과로, 데이터베이스 액세스, 데이터 조작 작업, 보기, 세부사항 및 업데이트 페이지 등의 웹 기반 사용자 인터페이스를 비롯한 전체 웹 애플리케이션이 생성되었습니다. 이 애플리케이션에 대한 다른 변형을 원할 경우 아티팩트를 삭제하고 다시 시작해야 하는 다른 마법사 기반 프레임워크와 달리, 이전 빌더 호출을 다시 열고 입력을 수정할 수 있으며 추가 빌더 호출을 추가 및 제거하여 생성된 애플리케이션을 사용자 정의할 수 있습니다.
학습서 뒷부분에서는 해당 빌더 입력의 논리 기반 사용자 정의가 가능하도록 프로파일링을 추가하는 방법에 대해서도 학습합니다. 이 기능을 통해 사용자 그룹이나 역할 또는 기타 사용자 정의 논리나 런타임 시 사용 가능한 정보에 따라 애플리케이션을 자동으로 변형할 수 있습니다. 기본 목록 사용자 인터페이스가 적합하지만 행 및 생성된 레이블이 모두 포함되어 있습니다. 이 학습서의 뒷부분에서는 생성된 사용자 인터페이스를 사용자 정의하는 방법을 보여줍니다.
을 클릭하여 이 모델에
추가할 수 있는 빌더 목록을 표시하십시오. | 이름 | 레이블 | 숨기기 | 정렬 | 필드 유형 |
|---|---|---|---|---|
| EMPNO | [직원 번호] | [항상 표시] | 설정 | 정수 |
| FIRSTNME | 이름 | [항상 표시] | [해제] | 문자열 |
| MIDINIT | 가운데 | [항상 표시] | [해제] | 문자열 |
| LASTNAME | [성] | [항상 표시] | 설정 | 문자열 |
| WORKDEPT | [업무 부서] | 테이블에서만 숨기기 | [해제] | 문자열 |
| PHONENO | [전화번호] | [항상 표시] | [해제] | 문자열 |
| GENDER | [성별] | 테이블에서만 숨기기 | [해제] | 문자열 |
| BIRTHDATE | [생일] | 테이블에서만 숨기기 | [해제] | 날짜: yyyy-MM-dd |
| SALARY | [봉급] | 테이블에서만 숨기기 | [해제] | 통화: #,###.00 |
| [이메일] | 테이블에서만 숨기기 | [해제] | 문자열 | |
| COMMENTS | [설명] | 테이블에서만 숨기기 | [해제] | 서식있는 텍스트 |
포틀릿 사용자 인터페이스에 대해 보다 의미 있는 개수의 열이 레코드 테이블 목록을 표시하는 초기 보기 페이지에 생겼는지 확인하십시오. 이때 각 보기의 항목을 편집, 삭제 및 작성하려고 시도해 보십시오.
이 학습서에서는 SQL 테이블 작성 빌더를 사용하여 샘플 데이터베이스에 대한 서비스 제공자 모델을 작성한 후 서비스 이용자 및 데이터 서비스 UI 빌더를 사용하여 사용자 인터페이스 서비스 이용자 모델을 작성했습니다. 그런 다음 데이터 필드 설정 빌더를 사용하여 사용자 인터페이스를 사용자 정의했습니다. 데이터베이스 테이블이 이미 있는 경우에는 위에서 사용한 SQL 테이블 작성 빌더(SQL 데이터 서비스를 랩핑하고 테이블 작성을 추가함) 대신 SQL 데이터 서비스 빌더를 직접 사용하십시오.
이제 애플리케이션에 프로파일링 기능을 추가하는 새 애플리케이션에서 프로파일링 사용 학습서를 수행할 준비가 되었습니다.
이 빠른 시작 안내서는 위젯을 작성하는 방법을 단계별로 설명합니다.
IBM Web Experience Factory를 사용하여 로컬로 설치된 IBM Lotus Mashup 서버에서 위젯을 실행, 테스트 및 공개할 수 있습니다.
로컬 개발 시스템에 Lotus Mashup 서버를 설치할 수 없는 경우에는 Lotus Mashup 서버의 원격 설치에 액세스할 수 있습니다.
다음 단계에 따라 Mashup 서버를 설정하십시오.
원격 Mashup Center에 배치할 경우 드라이브를 서버의 InstalledApps 폴더에 맵핑하면 자동 동기화 기능을 사용할 수 있습니다. 맵핑된 드라이브를 설정하지 않는 경우 프로젝트를 공개해야 프로젝트를 실행하여 변경사항을 확인할 수 있습니다.
다음 단계에 따라 Lotus Mashup와 함께 사용할 Web Experience Factory가 포함된 위젯을 작성하십시오.
사용 가능한 스프레드시트가 없으면 기본 스프레드시트가 제공됩니다. 기본 파일은 프로젝트에 학습서 및 샘플 기능 세트가 포함된 경우에 사용할 수 있습니다.
이 빠른 시작 안내서는 위젯을 로컬로 작성하여 테스트한 뒤 원격으로 IBM InfoSphere MashupHub에 업로드하는 방법을 단계별로 설명합니다.
그런 다음 위젯을 IBM Lotus Mashup에 공개하십시오. 원격 서버로 내보내기 전에 먼저 로컬로 설치된 Lotus Mashup 서버에 대해 개발하고 테스트하는 것이 좋습니다. 로컬 Lotus Mashup 서버를 설치할 수 없거나, 로컬로 테스트를 완료하고 원격 Lotus Mashup 서버에 공개할 준비가 된 경우 이 문서의 단계를 수행하십시오.
IBM Web Experience Factory는 Lotus Mashup과 함께 사용되어 mashup 페이지의 일부가 되는 위젯을 작성합니다. 일반적으로 개발자는 로컬 시스템에서 위젯을 작성하여 배치하고 로컬로 테스트합니다. 그러나 일부의 경우, 개발자가 로컬 Lotus Mashup 서버를 실행할 자원이 없는 환경에서 작업하거나 개발 팀의 여러 구성원이 위젯을 공통 Lotus Mashup 서버에 배치해야 하는 경우도 있습니다. 로컬 개발 및 테스트가 완료되면 팀은 새로 작성된 위젯을 원격 서버에 공개합니다. 원격 서버는 프로덕션 서버, 통합 서버 또는 품질 보증 서버일 수 있습니다.
Web Experience Factory는 IBM WebSphere Application Server Community Edition(CE) 애플리케이션 서버를 설치합니다. WebSphere Application Server CE는 Apache Geronimo 기반의 개방형 소스 J2EE(Java 2 Platform, Enterprise Edition) Application Server입니다. WebSphere Application Server CE는 Web Experience Factory용 경량 테스트 기능을 제공합니다. 이 환경에서 위젯을 테스트하고 실행할 수 있습니다.
일부 개발 환경에서는 많은 수의 사용자가 공통 서버에 액세스해야 합니다. Web Experience Factory가 Lotus Mashup 및 InfoSphere MashupHub와 통합되면 원격 서버로의 위젯 공개가 지원됩니다.
다음 단계에 따라 Lotus Mashup 서버를 설정하십시오.
Lotus Mashup 서버가 로컬인 경우 localhost를 유지하십시오. Lotus Mashup를 원격으로 실행 중인 경우 전체DNS 호스트 이름을 입력하십시오. 대부분의 경우 SOAP 커넥터 포트는 8880으로 남아 있을 수 있습니다.
원격 Lotus Mashup 서버에 배치하는 경우 자동 동기화 기능을 사용하려면 드라이브를 서버의 InstalledApps 폴더에 맵핑하십시오. 맵핑된 드라이브를 설정하지 않는 경우 변경사항을 확인하려면 실행 전에 프로젝트를 공개해야 합니다.
위젯을 작성하십시오.
사용 가능한 스프레드시트가 없으면 기본 스프레드시트가 제공됩니다. 기본 파일은 프로젝트에 학습서 및 샘플 기능 세트가 포함된 경우에 사용할 수 있습니다.
다음 단계에 따라 위젯을 InfoSphere MashupHub에 업로드하십시오.
주: 이미 로그인한 경우에는 로그아웃한 뒤 다시 로그인해야 합니다. 로그인 시에만 Lotus Mashup이 도구 상자를 새로 고칩니다.
프로젝트 및 모델을 작성하면 해당 모델에 빌더를 추가할 수 있습니다.
대부분의 잘 설계된 웹 애플리케이션은 서비스 지향 아키텍처(SOA)를 구현합니다. SOA 애플리케이션에서 백엔드 서비스를 호출하거나 서비스 호출에 필요한 사용자 인터페이스를 표시하는 모델을 작성합니다. 웹 애플리케이션 주제를 개발하면 사용자 인터페이스의 페이지 및 양식 작성 또는 백엔드 시스템 호출에 필요한 서비스 작성을 안내합니다.
서비스 지향 애플리케이션을 빌드하려면 서비스 제공자 모델과 서비스 이용자 모델을 작성해야 합니다.
프리젠테이션 레이어에 대한 하나의 코어 빌더가 있습니다.
서비스 정의 및 서비스 조작 빌더를 사용하여 서비스 제공자 모델을 작성할 수 있습니다.
여러 빌더를 사용하여 서비스 레이어를 작성할 수 있습니다.
SOA 애플리케이션을 구현하려면 서비스 제공자(백엔드 데이터 액세스) 또는 서비스 이용자(프론트 엔드 프리젠테이션) 중 하나인 모델을 작성한 후 애플리케이션 테스트 및 공개를 위해 이들을(유연하게) 결합합니다.
보통 데이터 소스가 둘 이상의 백엔드 시스템을 표시하는 경우에도 복수의 관련 조작으로 서비스를 정의하는 것이 유용합니다. 예를 들어, 고객 정보 서비스는 고객 목록(검색 기준 기반), 고객 세부사항 정보, 고객 주문, 고객 불만 등을 리턴하는 조작을 정의할 수 있습니다. 제품 서비스는 카테고리별 제품, 가격별 제품, 제품 자원 명세, 제품 비용, 제품 판매 실적 등을 위한 조작을 정의할 수 있습니다.
이 예제는 한 쌍의 단순 서비스 제공자 및 서비스 이용자(프리젠테이션) 모델을 사용합니다.
애플리케이션을 빌드하기 위해서는 본질적으로 다음 두 단계만 필요합니다.
이들 코어 부분이 제 자리에 있으면 다른 빌더를 추가하여 서비스 또는 이용자측을 원하는 대로 향상시킬 수 있습니다.
SOA(서비스 지향 아키텍처) 애플리케이션의 개발을 더욱 향상시키기 위해 IBM Web Experience Factory는 개발을 단순화 및 가속화하는 추가 기능을 제공합니다.
서비스 정의 빌더의 단추를 클릭하여 자동으로 스텁 서비스 모델을 작성할 수 있습니다. 이 모델은 원래 서비스 제공자 모델과 동일한 인터페이스를 갖지만 조작, 스키마 및 샘플 데이터의 완전한 자체 포함 스냅샷을 포함하는 완벽한 생성 모델입니다. 스텁 서비스 모델은 데이터 소스에 연결해야 하는 필요성을 생략하므로써 시스템 구성 노력을 줄이고 SAP, IBM Lotus Domino 또는 PeopleSoft 같은 실제 시스템으로의 연결 또는 시스템의 "개발자" 버전이 로컬에 있는지의 확인을 수행하지 않습니다. 원하는 경우 서비스를 한 번만 호출한 후 그 이후에는 연결이 끊어진 지원을 사용하여 얻는 실제 결과 데이터에서 샘플 데이터를 자동으로 캡처할 수 있습니다.
백엔드 시스템이 응답이 느리거나 제한된 가용성을 갖는 경우 이 연결이 끊어진 개발 접근을 사용하여 상당한 시간을 절약할 수 있습니다. 스텁 서비스 모델 사용은 생성 프로세스가 모든 재생성 주기 동안 느린 백엔드에 액세스할 필요가 없음을 의미합니다.
서비스 테스트 빌더를 사용하면 각 조작 테스트를 위한 기본 입력의 스펙을 포함하여 서비스 내에 정의되는 모든 조작을 테스트하는 데 필요한 페이지 및 코드를 자동으로 생성할 수 있습니다. 서비스 테스트 빌더를 사용하여 모든 프리젠테이션 계층과 완벽하게 독립이고 별도의 테스트 하니스를 빌드할 필요없이 용이하게 백엔드 기능의 유효성을 확인할 수 있습니다. 또한 브라우저 페이지를 볼 필요없이 자동화된 서비스 테스트 확립에 유용한 기능인 서비스 조작을 직접 호출하는 "headless" 메소드를 생성할 수 있습니다.
서비스 문서 빌더는 이 이중 아키텍처의 양쪽에 서비스 문서를 자동으로 생성합니다. 서비스 제공자 모델에 의해 작성되는 서비스 또는 서비스 이용자 모델에 의해 사용되는 서비스에 대한 입력 및 결과를 포함하여 서비스 및 서비스 조작에 대한 정보를 작성합니다. 또는 별도의 문서 모델을 사용하여 웹 애플리케이션 내의 모든 서비스에 대한 문서를 생성할 수 있습니다.
서비스 제공자 모델의 스와핑을 촉진하기 위해 데이터 서비스 빌더가 Java 인터페이스에 대한 개념과 유사한 서비스 인터페이스 개념을 지원합니다. 서비스 정의 빌더를 사용하여 인터페이스 정의로 사용하려는 다른 서비스 제공자 모델의 이름을 지정할 수 있습니다. 인터페이스 개념은 모두가 프리젠테이션(서비스 이용자) 모델의 공통 세트에 대해 작업하는 대체 서비스 제공자 구현을 개발하려는 경우에 매우 유용합니다. 프리젠테이션 모델을 분할하지 않고 서비스 제공자 모델 사이에서 스왑할 수 있게 합니다.
서비스 정의 및 서비스 조작 빌더는 자동으로 지정된 서비스 인터페이스를 정확하게 구현하기 위한 도움과 검증을 제공합니다(대체 구현은 자동으로 생성되지 않습니다). 서비스 이름, 조작 이름 및 조작 매개변수의 숫자와 이름이 검증됩니다. 입력 및 결과 유형이 검증에 포함되지 않으므로 대체 형식을 갖는 서비스를 구현하기 위해 Web Experience Factory의 적응성 기능을 강화할 수 있습니다.
IBM Web Experience Factory를 사용하여 클라이언트 측 애플리케이션을 개발할 수 있습니다.
클라이언트 측 웹 애플리케이션의 초기 페이지가 서버에서 로드되고 후속 요청은 클라이언트 모바일 디바이스의 업데이트된 보기를 렌더링하는 데 사용되는 JSON 데이터만 요청할 수 있도록 제한될 수 있습니다. 일반적으로 이와 같은 개발 기술은 최소한 비즈니스 로직의 일부(예: 애플리케이션 플로우 또는 클라이언트 측 유효성 검증)를 클라이언트에서 수행할 수 있도록 허용합니다.
모바일 웹 애플리케이션 개발에 클라이언트 측 접근 방식을 사용하면 다음과 같은 이점이 있습니다.
중요한 요구사항 및 제한사한
Web Experience Factory 클라이언트 측 웹 애플리케이션 개발의 기본 아키텍처는 클라이언트 디바이스에서 UI와 데이터가 결합되며 HTML, JavaScript 및 REST 서비스를 사용하는 JSP를 생성하고 렌더링하는 것입니다.
Dojo Mobile 및 데이터 레이아웃 템플리트
Dojo Mobile 테마 사용자 정의
클라이언트 모바일 애플리케이션의 Dojo Mobile 테마를 사용자 정의하려면 client_dojo_mobile.uitheme 파일을 편집하는 대신 이를 복사한 후 필요에 따라 테마 값을 편집하십시오. 편집 시 각 테마 특성의 기능 및 Dojo Mobile 클라이언트 애플리케이션에 적합하게 변경할 수 있는지 여부에 대해 설명하는 테마의 인라인 XML 설명에 유의하십시오.
프로젝트는 Web Experience Factory에서 애플리케이션의 기초입니다.
프로젝트에는 Web Experience Factory에서 웹 애플리케이션, 포틀릿 애플리케이션 또는 위젯을 빌드하는 데 필요한 모든 아티팩트가 들어 있습니다.
Web Experience Factory Designer 마법사는 프로젝트 조작(예: 프로젝트 작성, 프로젝트에 Web Experience Factory 아티팩트 추가, 프로젝트에서 Web Experience Factory 아티팩트 제거 및 프로젝트 설정 수정)을 수행하는 데 도움을 줄 수 있습니다.
대부분의 마법사는 프로젝트 마우스 오른쪽 단추 클릭 메뉴에서 액세스 가능하며 일반적으로 개발 환경에 따라 사용자가 변경할 수 있는 기본 설정을 제공합니다.
일반 Web Experience Factory 프로젝트에는 다음과 같은 특성이 있습니다.
기본적으로, Web Experience Factory 프로젝트는 Eclipse /workspace 디렉토리에 있습니다. 그러나 파일 시스템의 다른 위치에 Web Experience Factory 프로젝트를 배치할 수 있습니다. Windows 시스템의 경우 경로 이름 길이에 대한 제한조건 때문에 파일 시스템 맨 위 또는 이와 가까운 위치에 프로젝트를 배치할 수 있다는 장점이 있습니다.
애플리케이션을 빌드하는 첫 번째 단계는 프로젝트를 작성하는 것입니다.
작성된 프로젝트에는 애플리케이션에 필요한 모든 아티팩트 및 기능이 들어 있습니다.
/WEB-INF/config/override.properties
이
파일을 사용하면 프로젝트에서 최신 테마(bowstreet.themeFile 특성)
및 기본 RDD(Rich Data Definition) 파일(the bowstreet.baseRddFile 특성)을 이용할 수 있습니다.
테마 파일(/WEB-INF/factory/themes/blue_WPF7.uitheme)의
특성을 사용하면 조치 실행 후의 작업에서 포틀릿의 부분 페이지 새로 고치기와 관련된 스마트 새로 고치기
기능을 사용할 수 있습니다. RDD 파일의 특성은
사용자 인터페이스(UI)에 있는 페이지 자동화 필드와 열의 표시 및 유효성 검증을
위한 자동 설정을 제공합니다. 기본적으로
페이지 자동화 페이지에서 단일 RDD 파일(/WEB-INF/factory/data_definitions에 있음)이 사용됩니다. Web Experience Factory 프로젝트에 사용하는 경우 Eclipse 빌드 조작은 여러 조치를 수행합니다.
예를 들어, Java 소스를 클래스 파일로 컴파일하는 경우 소스 디렉토리의 특성 파일을 클래스 디렉토리로 복사합니다.
예를 들어, Application Server에 대한 출력 위치로 복사하거나 WAR 파일로 작성합니다.
자동 빌드 설정이 사용 가능한 경우( 아래의 자동으로 빌드) Web Experience Factory Designer의 성능이 가장 뛰어납니다. 기본적으로 이 설정은 사용 가능하지만 상황에 따라 소스가 많이 있는 작업공간에 다른 활성 프로젝트가 있는 경우 개발자가 이 설정을 끌 수도 있습니다. 끄지 않으면 빌드하는 시간이 오래 걸릴 수 있습니다.
다음 상황과 같이 이 설정을 사용 안함으로 설정한 상태에서 실행해야 하는 경우 수동으로 빌드해야 합니다.
프로젝트 작성을 완료한 후에는 개발 WAR 파일을 공개할지 또는 프로덕션 WAR 파일을 내보낼지 여부를 선택할 수 있습니다.
Web Experience Factory는 두 개의 WAR 파일을 생성할 수 있습니다. Web Experience Factory 개발 WAR 파일은 Application Server에서 독립형으로 애플리케이션을 실행하는 경우 사용됩니다. 포틀릿 WAR 파일은 포털 내의 포틀릿으로 애플리케이션을 실행하는 경우 사용됩니다.
애플리케이션 공개 기능을 선택하지 않은 경우에는 이 프로세스가 완료된 후 수동으로 WAR 파일을 공개해야 합니다. 애플리케이션 공개 기능을 선택한 경우 프로젝트의 서버 구성에 지정된 서버에 WAR 파일이 공개됩니다. 여기에서 많은 작업이 수행되므로 공개 프로세스는 완료되는 데 2 - 3분이 걸릴 수 있습니다.
WebSphere Portal의 로컬 설치를 사용하는 경우, WebSphere Application Server의 보안이 기본적으로 활성화됩니다. 따라서 배치 WAR 파일이 작성되는 동안 신임을 묻는 메시지가 표시될 수도 있습니다. 포털 관리자 신임이 아닌 WebSphere Application Server 관리자 신임을 사용하십시오. 또한 실행되지 않은 애플리케이션 공개 기능을 종료하기 전에 이 프롬프트를 기다려야 합니다. 프롬프트를 무시하면 시간 종료되어 WAR 파일이 자동으로 공개되지 않습니다. 이 경우에도, WebSphere Application Server 관리 콘솔을 사용하여 WAR 파일을 수동으로 설치하고 구성할 수 있습니다.
프로세스가 완료되면 Web Experience Factory는 설치된 기능 집합에 대한 README 편집기를 표시합니다. 이 파일을 잘 읽고 다 읽었으면 닫으십시오. 비어 있는(회색) 작업 영역이 남습니다.
Websphere Administration Server 또는 WebSphere Portal Server 서버가 원격이면 정보 패널 아래에 오류 메시지가 나타납니다. 이 메시지는 공개되지 않은 개발 WAR 및 EAR에 대해 설명합니다. 포틀릿 WAR을 자동으로 공개하지 않도록 선택했거나 포털 서버를 사용할 수 없는 경우 WebSphere Portal 관리 콘솔을 사용하여 WAR을 수동으로 공개해야 합니다.
개발 WAR 파일에는 개발 시간을 단축하는 데 도움이 되는 유틸리티가 포함되어 있습니다. 개발 WAR은 서버 구성에 제공된 입력을 기초로 빌드됩니다. 서버 구성이 애플리케이션 공개에 적합하도록 구성된 경우 개발 WAR을 빌드할 때 위젯이 공개됩니다. Web Experience Factory 설치 시 시스템에 Mashup 서버가 설치되어 있는 경우 MashupServer라는 서버 구성이 자동으로 생성되고 설치 중에 올바른 신임이 제공되는 한 자동으로 위젯을 공개하도록 구성됩니다.
개발 WAR을 빌드하려면 프로젝트 탐색기 패널에서 프로젝트 이름을 마우스 오른쪽 단추로 클릭하십시오. 를 클릭하여 위젯을 공개하십시오. 공개할 위젯을 선택하고 확인을 클릭하십시오.
프로덕션 환경에 애플리케이션을 내보낼 준비가 된 경우 프로덕션 WAR 파일이 사용됩니다. 프로덕션 WAR이 개발 유틸리티에 들어 있지 않으며 개발 WAR보다 작습니다. 프로덕션 WAR을 수동으로 서버에 내보내야 합니다. 프로덕션 WAR을 빌드하려면 프로젝트 탐색기 패널에서 프로젝트 이름을 마우스 오른쪽 단추로 클릭하십시오. 를 클릭하여 사용자 환경에 고유한 WAR을 선택합니다.
애플리케이션 공개 기능을 선택하지 않은 경우에는 이 프로세스가 완료된 후 수동으로 WAR 파일을 공개하거나 내보내야 합니다. 애플리케이션 공개 기능을 선택한 경우 WAR 파일이 서버에 공개됩니다. 여기에서 많은 작업이 수행되므로 공개 프로세스는 완료되는 데 2 - 3분이 걸릴 수 있습니다.
Lotus Mashup의 로컬 설치를 사용하는 경우, 보안이 기본적으로 활성화됩니다. 따라서 배치 WAR 파일이 작성되는 동안 신임을 묻는 메시지가 표시될 수도 있습니다. WebSphere Application Server 관리자 신임을 사용하십시오. 또한 실행되지 않은 공개 프로세스를 종료하기 전에 이 프롬프트를 기다려야 합니다. 프롬프트를 무시하면 시간 종료되어 WAR 파일이 자동으로 공개되지 않습니다. 이 경우에도, WebSphere Application Server 관리 콘솔을 사용하여 WAR 파일을 수동으로 설치하고 구성할 수 있습니다.
프로세스가 완료되면 Web Experience Factory는 설치된 기능 집합에 대한 README 편집기를 표시합니다. 이 파일을 잘 읽고 다 읽었으면 닫으십시오. 비어 있는(회색) 작업 영역이 남습니다.
Lotus Mashup 서버가 원격이면 정보 패널 아래에 오류 메시지가 나타납니다. 이 메시지는 공개되지 않은 개발 WAR 및 EAR에 대해 설명합니다. WAR을 자동으로 공개하지 않도록 선택했거나 서버를 사용할 수 없는 경우 WAR을 수동으로 공개하거나 내보내야 합니다.
다양한 방식으로 Web Experience Factory 프로젝트를 수정할 수 있습니다.
예를 들어, 기능 세트를 해당 프로젝트에 추가하거나 전혀 다른 유형의 Application Server에 프로젝트를 공개할 수도 있습니다. 또한 프로젝트에서 WAR을 작성하여 프로젝트를 수정할 수도 있습니다. 이러한 모든 옵션은 프로젝트 팝업 메뉴에서 사용 가능하고 프로젝트 탐색기에서 프로젝트를 마우스 오른쪽 단추로 클릭하여 이 옵션에 액세스합니다.
팝업 메뉴에서 을 클릭하여 기능 세트를 추가하십시오. 기능 정보 분할창에서 프로젝트에 사용할 빌더가 포함된 기능 세트를 선택할 수 있습니다.
다양한 WAR 유형을 빌드할 수 있습니다. 팝업 메뉴에서 애플리케이션 공개를 클릭하고 하위 메뉴에서 적합한 항목을 선택하십시오.
을 클릭하여 프로젝트에서 사용 가능한 서버 구성을 보거나 변경할 수 있습니다.
다음과 같은 간단한 지침을 참고할 경우 원격 시스템에 있는 프로젝트에 대한 작업을 수행할 수 있습니다.
원격 프로젝트는 여러 개발자가 동일한 프로젝트에 대한 액세스를 공유할 수 있는 팀 개발을 지원합니다.
원격 프로젝트는 IBM Web Experience Factory 위치를 J2EERoot\.bowstreet 구성 파일에 저장합니다. 결과적으로 2명 이상의 사용자가 동일한 원격 프로젝트에 대한 작업을 수행하는 경우 해당 사용자는 모두 프로젝트에 대해 정확히 동일한 디렉토리 위치를 사용해야 합니다. 기존 원격 프로젝트를 사용자의 작업공간에 가져오려고 하지만 사용자 경로가 원격 프로젝트 .bowstreet 구성 파일에 지정된 경로와 일치하지 않는 경우, Web Experience Factory Designer에 오류가 표시될 수 있습니다.
프로젝트 탐색기 또는 모델 네비게이터의 프로젝트 트리에서 폴더가 표시되는 위치를 변경할 수 있습니다.
프로젝트 탐색기 트리에서 항목을 이동하려면 다음 단계를 수행하십시오.
빌더 및 프로파일 항목의 이름을 바꿀 수 있으며 경우에 따라서는 해당 정의도 편집할 수 있습니다.
빌더 또는 프로파일 항목의 이름을 바꾸는 경우, 참조 조정에서 이름 바꾸기 프로세스는 해당 참조에 대해 내부적으로 단순 텍스트 검색을 수행한다는 점도 고려해야 합니다. 예를 들어, 이름이 Page2인 빌더 및 Page20인 빌더 중에서 Page2를 Pagex로 이름을 변경하는 경우, Page2와 Page20에 대한 참조를 찾을 수 있습니다. Page20에 대한 참조를 골라내려면, 이름 바꾸기 프로세스로 인한 변경사항을 미리 확인하여(>다음을 클릭하여 미리 보기) 변경하지 않을 항목을 선택 취소해야 합니다.
프로파일 항목 또는 빌더 호출의 이름을 변경하려면 다음 단계를 수행하십시오.
폴더, 모델 또는 프로파일 세트의 이름을 바꿀 수 있습니다.
모델 네비게이터에서 자원의 이름을 바꾸려면 자원을 마우스 오른쪽 단추로 클릭하고 팝업 메뉴에서 이름 바꾸기를 선택한 후 새 이름을 입력하십시오.
IBM Web Experience Factory는 프로젝트 탐색기 및 Java 패키지 탐색기를 통해 리팩토링을 확장 지원합니다.
프로젝트 탐색기에서 자원을 이동하거나 이름을 바꿀 때 모든 내부 참조가 조정되기 때문에 프로젝트 탐색기를 통해 리팩토링하도록 권장합니다. 이는 표준 네비게이터에서 리팩토링을 시도하는 경우에는 적용되지 않습니다.
프로젝트 탐색기에서 IBM Web Experience Factory Designer의 리팩토링 기능을 활용하여 프로젝트 폴더 또는 이 폴더가 들어 있는 자원을 이동하거나 이름을 바꿀 수 있습니다.
트리에서 자원을 이동하려면 프로젝트 탐색기에서 해당 항목을 클릭하고 리팩터, 이동을 차례로 클릭한 다음 나타나는 대화 상자에서 항목을 이동할 폴더를 클릭하십시오. 또는, 해당 항목을 마우스 오른쪽 단추로 클릭하고 메뉴에서 을 선택한 다음 나타나는 대화 상자에서 항목을 이동할 폴더를 클릭하십시오.
Eclipse 내보내기 기능을 사용하여 개발 시 공유할 아티팩트를 포함하는 IBM Web Experience Factory 아카이브 파일을 작성하십시오.
Web Experience Factory 아카이브를 작성하는 경우 모델 및 지원 파일만 선택하십시오. 여기에는 HTML 페이지, .css 파일, JavaScript 파일, 프로파일, 자원 번들 및 LJO에 대해 작성하는 모든 Java 소스 파일 등이 포함됩니다.
기본적으로 새 프로젝트에 포함되는 모든 파일은 포함하지 마십시오. Web Experience Factory 아카이브에 기타 프로젝트 파일을 포함하는 경우 기타 프로젝트로 가져올 때 아카이브에 문제점이 발생할 수 있습니다. 프로젝트 파일 중 일부가 해당 프로젝트 전용일 수 있으므로 문제점이 발생합니다. 양호한 선택 규칙은 작성하는 파일만 포함하는 것입니다.
Web Experience Factory 아카이브 가져오기 마법사를 사용하여 외부 소스로부터 프로젝트에 자원을 통합할 수 있습니다.
기능 세트는 배치 팀 구성원이 사용하도록 기능을 패키지화하는 간편한 방법을 제공합니다.
기능 세트는 빌더 또는 빌더 세트에 필요한 파일 세트입니다. 기능 세트에는 모델, 프로파일 세트, 빌더 및 클래스가 포함될 수 있습니다. 기능 세트는 애플리케이션 및 구현 중인 기능과 관련이 없는 WAR 파일에 오버헤드를 추가하지 않습니다. 언제라도 프로젝트에 기능 세트를 추가하거나 프로젝트에서 기능 세트를 제거할 수 있습니다.
IBM Web Experience Factory 프로젝트에 기능 세트를 추가하려면 이 프로시저를 따르십시오.
프로젝트에서 Web Experience Factory 기능 세트를 제거할 수 있습니다.
기능 세트를 제거하면 기능 세트와 관련된 모든 파일이 프로젝트에서 제거됩니다.
빌더에 사용되는 특정 파일에 문자 인코딩을 설정할 수 있습니다.
다양한 모델을 작성하는 경우 마법사를 사용하면 도움이 됩니다.
이 마법사는 기본 애플리케이션을 실행하는 데 필요한 모든 빌더로 모델을 채웁니다. 마법사는 자체 문서를 제공하고 쉽게 사용하도록 설계되었습니다. 마법사에 표시되는 선택은 프로젝트에 추가하는 기능 세트에 따라 다릅니다. 마법사의 진행 단계는 작성하려는 모델 유형에 따라 다릅니다.
IBM Web Experience Factory Designer 마법사를 사용하여 새 모델을 작성합니다.
프로젝트 탐색기 또는 모델 네비게이터에서 모델을 열 수 있습니다.
기존의 모든 모델은 IBM Web Experience Factory WEB-INF/models 디렉토리에 저장되어 있습니다. 모델 네비게이터는 프로젝트 탐색기의 서브세트를 표시하여 모델 및 프로파일에 대한 액세스를 용이하게 합니다.
모델을 열면 Web Experience Factory Designer에서 다음과 같은 모델 관련 패널을 표시합니다.
다음 단계에 따라 서비스 제공자를 테스트하십시오.
빌더 호출을 추가하여 모델을 열 수 있습니다.
모델의 기존 빌더에 대해 빌더 호출 편집기를 실행할 수 있습니다.
선택된 빌더 호출의 편집기가 빌더 호출 편집기 보기의 모델 탭에 열립니다.
빌더의 유형을 다른 유형으로 변환하려면 다음 단계를 수행하십시오.
이 단계는 링크 빌더로 변환 중인 단추 빌더를 예제로 사용합니다.
빌더가 선택된 유형으로 변환되고 변환을 반영하도록 빌더 호출 목록이 업데이트됩니다.
원래 빌더 입력은 보존되며, 해당되는 경우 새 빌더에 지능적으로 적용됩니다. 인용된 예제에서, 단추 레이블 입력 값이 링크 텍스트 입력에 적용됩니다. 원래 빌더의 모든 입력이 새 빌더 편집 페이지에 추가됩니다.
빌더 호출 팝업 메뉴에서 변환 대상을 사용하여 한 유형에서 다른 유형으로 빌더를 변환할 수 있습니다.
변환은 유사하고 동등한 입력을 가진 특정 빌더에 대해 작동합니다. 단추 및 링크 빌더가 일반적인 예를 제공합니다. 이런 빌더는 유사하며, 거의 동일한 입력을 갖습니다. 따라서 이상적인 변환 후보입니다. 변환에 이상적으로 적합한 또다른 빌더 쌍은 페이지 및 가져온 페이지 빌더입니다.
일반적으로, 빌더 변환은 동일한 카테고리의 빌더를 포함해야 합니다. 예를 들어, 페이지 제어사항 카테고리 또는 페이지 수정자 카테고리 내에서 한 빌더 유형에서 다른 빌더 유형으로 변환하십시오. 속성 또는 설계면에서 근본적으로 다른 빌더를 변환하려고 시도하지 마십시오.
목록 정렬은 비숫자 방식으로 목록을 구성하려는 경우에 유용합니다.
모델을 닫으면 모델 작업공간에서 해당 탭이 제거됩니다.
모델을 삭제하면 프로젝트에서 모델이 제거됩니다.
공개된 애플리케이션에서 모델도 제거해야 합니다.
모델의 이름을 바꾸려면 다음 중 하나를 선택하십시오.
모델을 저장하면 모든 빌더 호출의 변경사항 및 모델 특성의 변경사항이 디스크의 모델 파일에 모두 커미트됩니다.
]을 클릭하십시오.모델을 실행(시작)하기 전에 하나 이상의 IBM Web Experience Factory 모델 실행 구성을 작성해야 합니다.
실행 구성을 정의한 방법에 따라 다음을 수행할 수 있습니다.
브라우저 창에 URL을 입력하여 모델을 실행할 수도 있습니다.
URL을 지정하여 모델을 실행하면 모델에서 특정 조치를 호출하고 모델에 명시적 프로파일을 전달할 수 있습니다.
http://localhost:7001/mymodels/CustomerModel/Action!GetCustomers
프로젝트가 공개된 경우, 활성 모델 편집기에서 현재 모델을 실행할 수 있습니다.
다음 메소드 중 하나를 사용하십시오.
Eclipse는 실행된 프로그램의 히스토리를 유지합니다. 이전에 실행한 모델을 다시 실행하려면 을 클릭하고 목록에서 이름을 클릭하십시오.
브라우저 창에 URL을 입력하여 모델을 실행할 수 있습니다.
프로파일을 지정하여 URL에서 모델에 적용할 수 있습니다.
또는 적용된 프로파일 보기를 사용하여 활성 모델 편집기의 모델에 프로파일 조합을 적용한 후 활성 모델을 실행할 수 있습니다.
IBM Web Experience Factory Designer에서 이름 지정된 모델을 실행할 수 있습니다.
Eclipse 비교 편집기를 사용하여 IBM Web Experience Factory 프로젝트에서 모델을 비교할 수 있습니다.
모델 비교 편집기는 모델 파일이 다른 모델 파일과 비교되거나 로컬 작업공간 히스토리 또는 저장소의 동일 모델의 다른 버전과 비교할 때 실행됩니다. 모델 비교 편집기는 표준 Eclipse 비교 편집기와 같은 방식으로 작동합니다.
비교 편집기는 비교/패치 환경 설정 페이지의 설정을 사용합니다. 를 클릭하여 설정을 보고 변경하십시오.
비교에서는 Eclipse 구조 뷰어와 비교 편집기가 사용되어 프로젝트의 두 모델 사이의 차이를 표시합니다.
모델 파일이 비교될 때 모델 비교 편집기가 편집기 영역에 열립니다. 모델 비교 편집기는 모델 구조 비교 보기와 모델 비교 편집기로 구성됩니다.
모델 구조 비교 보기에서 상위 레벨 노드를 선택할 때 모델 비교 편집기는 모델 편집기가 활성화될 때의 아웃라인 보기와 유사한 빌더 호출 비교를 표시합니다. 트리에서 빌더 호출 노드나 빌더 입력 노드를 선택하는 경우 모델 비교 편집기는 선택된 노드의 비교를 XML 텍스트로 표시합니다.
모델 비교 편집기에서, 빌더 호출 목록에서 모든 차이를 찾아보고 비교된 자원 사이에 강조표시된 차이를 복사할 수 있습니다. 모델 비교 편집기에서 작성한 자원 변경사항을 저장할 수 있습니다. 비교 편집기의 도구 모음을 사용하면 도구 모음 단추에서 다음 명령을 사용할 수 있습니다.
컨테이너에 모델을 배치하여 웹 페이지에 모델을 삽입할 수 있게 합니다.
모델은 자체 포함을 작성할 수 있는 빌더 호출의 콜렉션입니다.
모델 컨테이너를 사용하여 모델을 자체 포함으로 만들고 웹 페이지에 삽입될 수 있게 합니다. 모델 컨테이너에서 여러 모델을 사용하는 것은 다음 두 가지 장점을 제공합니다.
여러 개발자는 컨테이너 빌더를 사용하여 페이지의 부분을 개발한 후 별도의 모델을 페이지에 추가할 수 있습니다. 각 모델이 표시될 모델에 대한 위치 표시기인 컨테이너에 지정됩니다. 모델은 컨테이너 안에 모델의 무제한 중첩을 허용하면서 컨테이너를 포함할 수도 있습니다. 페이지에 액세스하는 사람의 관점에서, 페이지는 한결같은 전체로서 표시되어 컨텐츠의 모자이크를 제공합니다. 그러나 사용자가 세부사항을 보기 위해 각 모델을 계속 클릭하는 경우 페이지의 전체 컨텍스트는 일정하게 유지되면서 페이지의 특정 모델 세그먼트만 변경됩니다.
6.1.2 이전 버전의 IBM Web Experience Factory Designer를 사용하는 경우 모델을 추가하여 협업 포틀릿 소스 빌더가 인식되게 하려면 Web Experience Factory Designer에서 기존 모델을 열고 다시 생성한 후 저장하십시오.
각 모델은 고유한 오류 페이지 및 오류 데이터를 선언해야 합니다.
가능하면 다음 지침을 따르십시오.
또한 모델 컨테이너 빌더를 사용하여 오류가 발생할 때 로드할 모델을 지정할 수 있습니다. 이 모델은 오류 메시지 및 가능하면 다른 페이지에 대한 링크를 표시할 수 있습니다.
프로젝트에 사용되는 모델의 보고서를 생성할 수 있습니다.
모델 검사 도구는 프로젝트에 있는 모델에 대한 보고서를 생성합니다. 이 보고서는 모델이 구성되는 방법 및 모델이 몇몇 문서화된 우수 사례를 따르는지 여부를 요약합니다.
프로젝트를 Web Experience Factory Designer에서 연 경우에는 요약 보고서 및 사용된 모델 분석을 생성하고 볼 수 있습니다. 출력은 HTML 파일 및 여러 CSV 파일로 구성되어 있습니다. HTML 파일은 모델을 개선하는 데 사용할 수 있는 우수 사례에 대한 힌트와 팁을 제공합니다.
생성된 모델 보고서의 컨텐츠는 정의된 검사에 의해 판별됩니다.
모든 보고서는 프로젝트의 Reports 디렉토리에 작성됩니다. 보고서 파일은 다음 표준 형식으로 이름이 지정됩니다.
Model Report for project name – time.html
name 값은 프로젝트 이름을 표시합니다. time 값은 보고서가 생성된 날짜와 시간을 표시합니다. 몇몇 기본 검사는 또한 보고서에서 빌더 사용법 통계를 포함하는 CSV 파일을 생성하기도 합니다. 이러한 CSV 파일을 사용하면 데이터를 사용자 필요에 맞게 정렬 및 재배열할 수 있습니다. 모든 보고서 파일은 같은 실행 중에 생성된 파일을 식별할 수 있도록 시간이 같습니다.
검사는 우수 사례를 따르지 않거나 유지하고 이해하기 어렵도록 빌드되었을 수도 있는 모델을 빠르게 식별하는 데 도움이 됩니다. 기본 검사 세트는 Web Experience Factory 엔지니어링 팀이 고객 모델을 검토할 때 만나게 되는 가장 흔한 몇몇 문제점에 중점을 둡니다. 예를 들어, 공통 문제점은 사용자 인터페이스(UI)와 데이터 액세스 빌더를 제공자(데이터 액세스) 및 이용자(UI) 모델로 분리하는 대신 하나의 모델에 혼합하는 것입니다.
기본 검사 세트는 Web Experience Factory 제품 위키에 문서화된 우수 사례를 기반으로 합니다.
\Designer\eclipse\plugins\com.bowstreet.designer.core_7.0.1\config
사용자 정의 검사 작성에 대한 자세한 정보는 Web Experience Factory 제품 위키를 참조하십시오.
애플리케이션의 페이지 및 양식은 데이터 보기 및 사용자와 애플리케이션 논리 및 데이터 사이의 상호작용을 제공합니다.
IBM Web Experience Factory 애플리케이션에서 이들 페이지는 일반적으로 정적이 아니며, 페이지에 대한 UI를 직접 판별하는 다양한 빌더뿐 아니라 페이지 컨텐츠에 간접적으로 영향을 주는 다른 빌더에 의해 변경됩니다.
개발 경로가 다르기 때문에 양식과 페이지는 구별됩니다. 양식 개발은 주로 데이터를 표시하고 프롬프트하는 UI를 구현하기 위한 두 개의 상위 레벨 빌더(예: 데이터 페이지 빌더 및 데이터 필드 수정자 빌더) 사용과 관련됩니다.
컨텐츠 페이지 개발은 HTML 기능(예: 페이지 빌더)의 여러 가지 측면을 구현하는 더 많은 수의 하위 레벨 빌더가 관련됩니다.
기존 HTML 또는 JSP 페이지를 모델에 가져오는 방식으로 웹 애플리케이션의 사용자 인터페이스를 구현할 수 있습니다.
이를 수행하려면 IBM Web Experience Factory Designer에서 가져온 페이지 또는 가져온 디렉토리 빌더를 사용하십시오. 프로토타입할 목적으로 페이지 빌더를 사용하여 단순 HTML 또는 JSP 페이지를 작성할 수 있습니다.
모델의 다른 파트와 상호작용하거나 다른 유형의 사용자에 대해 변수를 작성할 해당 페이지의 모든 파트에 대해, 페이지에 이름 지정된 <input /> 또는 <span /> 태그에 해당 빌더로의 호출을 지정하십시오. 예를 들어, HTML 선택 목록을 선택 빌더에 대한 호출로 바꿀 수 있습니다. 해당 작업을 수행하여 선택 가능한 옵션 및 모델의 다른 어딘가에 정의된 메소드, 변수 또는 사용자 입력의 선택 목록에 대한 기타 특성을 판별할 수 있습니다.
기존 HTML 및 JSP 페이지를 모델에 통합할 수 있습니다.
다음 방법 중 하나를 사용하십시오.
가져온 디렉토리 빌더는 지정된 디렉토리의 HTML 및 JSP 파일만 모델에 추가합니다.
Web Experience Factory 애플리케이션에서 여러 기술 중 하나를 사용하여 데이터를 표시할 수 있는데, 그 중 일부는 의도된 서버 환경을 대상으로 하며 서로 다른 자동화 정도를 채택합니다.
일반적인 규칙으로서 데이터 페이지 및 데이터 필드 수정자 빌더 사용을 시도하십시오. 데이터에 대해 다루기 힘들어 보이거나 원하는 표시 및 작동을 구현하려면 많은 데이터 필드 수정자 빌더 호출을 추가해야 하는 경우 하위 레벨 빌더 호출을 사용하십시오.
여러 방법으로 데이터 페이지 요소의 레이아웃을 수정할 수 있습니다.
대부분의 페이지에서는 끌어서 놓기 조작을 사용하여 열과 행의 순서를 다시 지정할 수 있습니다. Web Experience Factory Designer 팔레트에서 레이아웃 도구를 사용하여 레이아웃 패턴을 끌어서 설계 패널의 페이지에 놓을 수도 있습니다.
데이터 레이아웃 빌더를 사용하여 모델에서 데이터 페이지 필드를 데이터 레이아웃 템플리트의 대상으로 맵핑하고 필드 유형을 설정하십시오. 데이터 레이아웃 템플리트를 사용하면 재사용 가능한 사용자 정의 패턴에 대한 지원을 설정할 수 있습니다.
이 기능을 사용하면 HTML 페이지 레이아웃을 완전히 제어하고 페이지의 자동 생성을 효율적으로 사용하지 않도록 설정하고 모델에서 페이지 자동화 지원의 장점을 잃게 됩니다. 이 기능은 몇몇 비정상적인 레이아웃이 있고 표시를 정확하게 제어해야 하는 경우에만 사용하십시오.
설계 패널에서 끌어서 놓기 조작을 사용하여 페이지 자동화 요소를 수정할 수 있습니다.
데이터 레이아웃 템플리트를 사용하여 데이터 페이지 빌더 또는 데이터 페이지를 사용하는 빌더에 의해 작성된 페이지의 레이아웃을 수정할 수 있습니다.
지정된 데이터 레이아웃 템플리트 및 레이아웃 필드 맵핑은 데이터 레이아웃 빌더가 데이터 페이지 빌더에 의해 생성된 레이아웃을 수정하는 데 사용됩니다. 제품에 제공된 데이터 레이아웃 템플리트 중 하나를 사용하거나 사용자 고유의 템플리트를 사용하여 재사용 가능한 사용자 정의 패턴 지원을 제공할 수 있습니다.
모델 편집기의 팝업 명령을 통해 데이터 페이지 빌더에서 작성한 요소의 레이아웃을 직접 편집할 수 있습니다.
모델 편집기의 경우 데이터 페이지 빌더 또는 데이터 페이지 빌더를 사용하는 빌더(예: 보기 및 양식 또는 데이터 서비스 사용자 인터페이스)에서 작성한 요소에서 내보내기 기능을 사용할 수 있습니다. 변경 가능한 요소는 페이지, 테이블, 그룹 및 필드입니다.
데이터 레이아웃 명령을 사용한 경우 HTML 데이터 레이아웃 빌더가 모델에 추가되어 내보낸 HTML 파일에서 지정한 사용자 정의를 제공합니다. 빌더는 내보낸 파일을 사용하여 데이터 페이지의 이 부분으로 표시합니다.
전체 페이지 명령을 사용한 경우에는 가져온 페이지 빌더가 모델에 추가됩니다. 기존 페이지는 사용자 정의된 HTML 파일의 컨텐츠로 바뀝니다.
사용자 정의 항목을 제거하려면 빌더를 사용 안함으로 설정하거나 삭제하십시오. 다른 항목을 추가로 사용자 정의하려면 내보낸 HTML 파일을 편집하십시오.
다음 단계를 수행하여 페이지에 있는 이름이 지정된 요소의 클래스 또는 스타일을 추가하거나 수정하십시오.
데이터 페이지 빌더에서 작성된 데이터 항목 페이지에서 사용자 입력의 유효성 검증을 관리할 수 있습니다.
이러한 기술은 데이터 페이지 빌더를 사용하는 모든 빌더가 작성하는 페이지에도 적용됩니다.
데이터 항목 페이지는 데이터 항목으로 설정된 필드(전체 페이지가 표시 전용으로 설정된 경우도 포함)에서 데이터 페이지 빌더로 관리됩니다. (이 작업은 전체 페이지가 해당 방법으로 설정되지 않았다 하더라도 데이터 필드 수정자 빌더를 사용하여 필드 중 하나를 데이터 항목으로 수정한 경우에 일어날 수 있습니다.
데이터 페이지 빌더는 일반 사용자에 데이터 항목 페이지를 표시하고 사용자 응답을 유효성 검증을 관리합니다. 이 빌더는 설정에 따라 페이지의 JSP를 생성합니다. 또한(J2EE 서버가 값을 넣은) RequestInputs에서 값을 수집할 SaveData 메소드를 생성한 다음, 해당 값을 변수에 저장합니다. 마지막으로, 개별 필드에 대한 유효성 검증 조작을 작성하고 JSP 페이지에 유효성 검증 오류 메시지를 추가합니다.
필드의 유효성을 확인하고 일반 사용자에게 결과를 표시하는 과정 중에 다음과 같은 방법으로 제어할 수 있습니다.
맨 먼저 전체 오류 텍스트가 이동하는 범위를 추가하기 위해 페이지를 편집하십시오. 가져온 페이지 빌더를 열고 편집 페이지를 클릭하십시오. data로 이름 지정된 범위를 찾은 다음, HTML의 전체 행을 복제하여 두 번 표시되게 하십시오. 중복 행 중 하나에서 단어 data를 fullError로 변경하고 빌더 호출에서 확인을 클릭하십시오.
inputPage에 대한 데이터 페이지 빌더를 열고 필수 필드 및 입력 유효성 검증 설정까지 아래로 화면이동하십시오. 오류 배치를 필드의 왼쪽 독립 열로 변경하고 전체 오류 배치에 대해 fullError를 선택하십시오. 이제 모델을 다시 실행하고, 두 필드에 어떤 비수치 텍스트를 입력한 후 제출을 클릭하십시오. 오류 메시지의 배치 이동과 함께 오류 메시지가 "전체 오류" 위치에 복제됩니다. 계속하기 전에 먼저 오류 배치를 보다 더 바람직한 위치인 필드의 오른쪽으로 다시 변경하십시오.
일반적으로 사용자가 데이터 항목 페이지 채우기를 완료하고 해당 페이지를 제출했을 때 일부 조치가 실행됩니다. 때로는 유효성 검증 오류가 있었으면 다른 조치를 실행할 수도 있습니다. 데이터 페이지 빌더에는 두 가지 입력, 즉 성공 조치 및 실패 조치가 있습니다. 이 항목은 inputPage_NextAction 메소드 작성 시 사용되며, 웹 애플리케이션 보기에서 확인할 수 있습니다. 이 메소드를 살펴보면, 수행하는 모든 작업이 페이지에 유효성 검증 오류가 있었는지 확인하기 위해 테스트한 다음 적절한 조치를 호출하는 것임을 알 수 있습니다.
샘플에서와 같이 실패 조치를 비워 둔 경우, 기본 실패 조치는 해당 페이지로 리턴하는 것입니다.
기본적으로 개별 필드 검사기는 스키마, WSDL 문서 또는 기타 메커니즘에 정의된 필드의 유형에 따라 생성됩니다. 스키마에서 유효성 검증 설정을 사용하여 데이터 페이지 빌더에서 이 작동을 사용할 수 없으며 검사기는 자동으로 생성되지 않습니다. 그러나 이 작동을 사용할 수 없는 경우에도 역시 데이터 필드 수정자를 사용하여 개별 검사기를 수동으로 설정할 수 있습니다.
데이터 필드 수정자를 새로 작성하고 inputPage의 필드 중 하나만 선택하십시오. 형식화 그룹을 열고 포맷터 com.bowstreet.builders.webapp.pageautomation.StandardFormatter를 선택하십시오. 이 경우 유효성 검증 표현식을 포함하여 추가 입력이 표시됩니다. 고유 검사기를 선택하십시오(단, 이 필드에 대해 호출 중인 서비스 호출의 기대값이 숫자임을 기억하십시오.) 일반 표현식(일반 표현식 문자열)을 선택하면, 정규 표현식 문자열을 입력할 새 입력이 제공됩니다. 해당 선택사항이 여기서 사용 가능하므로 이 설정은 필드에 대한 필수/선택적 값을 대체합니다. 새 유효성 검증 문자열을 확인하려면 유효성 검증자 변경 및 모델을 다시 실행하십시오.
사후 저장 메소드의 작동을 제어하고 교차 필드 유효성 검증을 수행하는 데 이를 사용할 수 있습니다. RequestInputs의 데이터가 변수에 다시 저장된 후 코드를 수행할 추가 작업이 있는 경우도 있습니다. 사후 저장 메소드 입력은 이 프로세스에 대해 Java 코드를 추가하기 위해 사용하는 훅입니다. 또한 수행할 작업이 데이터 항목에 대해 추가 유효성 검증이거나 개별 필드 유효성 검증보다 더 복잡한 과정이 있는 경우, 실패 조치를 강제로 수행하여 유효성 검증을 실패로 야기하며 사용자에게 표시되는 오류 메시지를 포함시키는 사후 저장 메소드 방법이 있습니다.
메소드 빌더를 새로 작성하고 이름을 TestLatitudes로 지정하십시오. 리턴 유형을 문자열로 설정하고 메소드 본문을 다음 컨텐츠로 채우십시오.
{
double lat1 = webAppAccess.getVariables().getDouble("MyServiceCall_arg1_lat1");
double lat2 = webAppAccess.getVariables().getDouble("MyServiceCall_arg3_lat2");
if (lat1 == lat2)
return "Make the latitudes different.";
else
return null;
}
코드는 변수에서 두 개의 위도 입력 값을 가져와서(데이터 페이지 빌더에서 이미 저장된 경우) 값이 같은지 검사하여 확인합니다. (이 변수의 정확한 이름은 웹 애플리케이션 보기를 살펴보고 변수를 작성한 서비스 호출 빌더를 선택하여(열지 않음) 식별됩니다.)
두 값이 같으면 코드는 텍스트를 리턴합니다. 이 텍스트는 inputPage_SaveData 메소드에 의해 오류 메시지로 해석됩니다. 두 값이 다르면 코드는 널(null)을 리턴합니다. SaveData 메소드가 인지하게 되는 이 리턴 값은 사후 저장 메소드가 오류를 찾지 못했음을 의미합니다. 모델을 실행하고 두 값을 동일하게 설정하면 오류 메시지가 표시되는 것을 볼 수 있습니다. 이 오류는 특정 필드와 연관되어 있지 않아 메시지가 전체 오류 섹션에만 표시됩니다.
단지 일정 작업만 수행할 뿐 오류를 리턴하지 않는 사후 저장 메소드를 작성할 경우, 해당 리턴 유형을 void로 설정할 수 있습니다. 또한 사후 저장 매소드는 개별 필드 유효성 검증이 오류 없이 실행된 경우에만 호출할 수도 있고, 그것과는 관계없이 해당 메소드를 호출할 수도 있습니다. 데이터 페이지 빌더에서 사후 저장 메소드 작동 입력으로 이 작동을 제어할 수 있습니다.
모든 데이터 항목 페이지에서 데이터 페이지 빌더는 오류 메시지 관리자 역할을 하는 링크된 Java 오브젝트를 작성합니다. 웹 애플리케이션 보기에서 LJO inputPageError를 선택하면, 사용 가능한 메소드가 표시됩니다. 사후 저장 메소드의 개별 필드 오류 메시지를 설정하려면 이 메소드를 사용할 수 있습니다. 각 유효성 검증자에게 너무 복잡한 경우였거나 사후 저장 메소드를 사용하려 하였으므로 일부 개발자는 사후 저장 메소드에 이를 설정합니다.
또한 오류 메시지의 표시를 데이터 페이지 빌더가 관리하게 하지 않고 사용자가 직접 관리할 경우, 개별 메시지를 직접 가져올 수 있습니다. 새 데이터를 포함하는 페이지로 리턴 중인 경우 수행해야 할 메시지를 지울 수도 있으며, 페이지의 마지막 방문 시간 이후로 계속 남아 있을 수 있는 메시지도 지워야 합니다.
데이터 입력 필드의 유효성 검증에 사용되는 일부 설정을 수정할 수 있습니다.
IBM Web Experience Factory의 모델 편집기에서 페이지 및 설계 패널을 사용하여 변경할 양식 또는 페이지를 볼 수 있습니다.필드 유효성 검증 설정(예: 오류 문자열)을 변경하려면 데이터 필드 설정 빌더를 사용하십시오.
모델 편집기에서 마우스 오른쪽 단추 클릭 메뉴를 사용하여 열 또는 필드를 표시하는 데 사용되는 일부 설정을 수정할 수 있습니다.
IBM Web Experience Factory의 모델 편집기에서 페이지 및 설계 패널을 사용하여 변경할 양식 또는 페이지를 볼 수 있습니다. 필드 표시 설정(예: 레이블)을 변경하려면 데이터 필드 설정 빌더를 사용하십시오.
데이터 정의는 서식있는 데이터 정의(RDD) 파일이라는 XML 파일에서 읽어옵니다.
서식있는 데이터 정의는 표시할 필요가 없는 열을 숨기는 등의 방법으로 포틀릿 또는 위젯을 정리하는 데 사용되며, 모델 내의 스키마와 연관됩니다. 선택한 스키마의 각 필더마다 레이블, 제어 유형, 검색 테이블, 형식화, 유효성 검증 등을 지정할 수 있습니다.
데이터 정의 파일은 사용자 인터페이스(UI) 설명을 스키마와 연관시키는 방식으로 작동합니다. 페이지 요소(예: 데이터 페이지 빌더 또는 보기 및 양식 빌더 사용)를 생성하는 데 스키마를 사용하면 모든 UI 특성이 자동으로 페이지에 적용됩니다. 또한 데이터 필드 수정자 빌더의 기능을 사용하여 특정 설정(예: 유효성 검증 및 형식화)에 대해 학습할 수 있습니다.
/WEB-INF/factory/data_definitions/
RDD 파일 base_datadef.xml 및 dojo_base_datadef.xml이
제공됩니다. override.properties 파일에서 다음 특성을
정의하여 프로젝트에 대한 기본 설정을 대체할 수 있습니다. bowstreet.baseRddFile
이 특성에 대한 기본 설정은 bowstreet.properties 파일에 있습니다.
여러 개의 파일을 정의할 수는 있지만, 처음 발견된 파일만 사용됩니다. 데이터 필드 설정 빌더의 기본 RDD 파일 입력을 사용하여 모델의 프로젝트에 대한 기본 RDD 파일을 대체할 수 있습니다.
빌더를 사용하여 페이지 자동화 양식 및 페이지의 열과 필드에 대해 웹 애플리케이션의 스키마와 연관된 데이터 정의 정보를 수정할 수 있습니다. 데이터 정의는 데이터 페이지 빌더의 내부 데이터 구조 중 하나입니다. 데이터 페이지에 스키마 유형 변수가 사용되면 데이터 페이지는 웹 애플리케이션의 스키마에 첨부된 데이터 정의 정보를 검색합니다. 데이터 정의 특성은 스키마를 기초로 하는 페이지의 기본값이 됩니다. 그러나 여전히 데이터 필드 설정, 데이터 열 수정자 및 데이터 필드 수정자와 같은 다른 빌더를 사용하여 스키마와 연관된 데이터 정의에 지정된 특성을 대체할 수 있습니다.
스키마 요소에 대한 데이터 정의의 연관은 요소 이름을 사용하여 수행됩니다. 데이터 정의 파일은 일반적으로 구조의 각 필드에 하위 데이터 정의가 포함된 구조 세트를 저장합니다. 스키마의 상위 (구조) 이름은 데이터 정의 파일의 상위 이름과 일치해야 하고 이에 따라 개별 필드도 이름과 일치합니다.
서식있는 데이터 정의 파일에는 다양한 자동 맵핑 및 데이터 정의 특성이 사용됩니다.
<SchemaTypeMappings>
<SchemaTypeMap type="date">base_Date</SchemaTypeMap>
<SchemaTypeMap type="boolean">base_CheckBox</SchemaTypeMap>
<SchemaTypeMap type="string">base_String</SchemaTypeMap>
<SchemaTypeMap type="string_enumeration">base_Select</SchemaTypeMap>
<SchemaTypeMap type="char">base_ShortString</SchemaTypeMap>
<SchemaTypeMap type="integer">base_Integer</SchemaTypeMap>
<SchemaTypeMap type="int">base_Integer</SchemaTypeMap>
<SchemaTypeMap type="byte">base_Integer</SchemaTypeMap>
<SchemaTypeMap type="short">base_Integer</SchemaTypeMap>
<SchemaTypeMap type="long">base_Integer</SchemaTypeMap>
<SchemaTypeMap type="double">base_FloatingPoint</SchemaTypeMap>
<SchemaTypeMap type="float">base_FloatingPoint</SchemaTypeMap>
<SchemaTypeMap type="decimal">base_Integer_Internal</SchemaTypeMap>
</SchemaTypeMappings>
사용자 고유의 정의를 여기에 포함할 수
있습니다. 유형은 일치할 스키마 유형입니다. 이는 데이터 필드 설정 빌더에서 필드의 필드 유형에 나타나는 값입니다. SchemaTypeMap 선언의 텍스트는 일치가 발견될 때 사용할 데이터 정의입니다. string_enumeration은 특수한 유형에 해당됩니다. 실제 스키마 유형이 문자열이고 열거가 있거나 선택항목이 정의된 경우 노드 리프가 이 유형을 사용합니다.
필드 설정(데이터 입력 필드의 경우 유효성 검증 설정)에 대한 일부 공통 특성은 데이터 필드 설정 빌더와 Web Experience Factory Designer의 특성 보기에 표시됩니다. 그러나 다른 특성은 어떠한 빌더 호출 편집기에도 표시되지 않습니다. 이러한 특성을 사용하려면 이를 프로젝트 기본 데이터 정의 파일 dojo_base_datadef.xml 또는 base_datadef.xml에 직접 추가해야 합니다.
<Attributes>
<Attribute>
<Name>color</Name>
<Value>black</Value>
</Attribute>
<Attribute>
<Name>size</Name>
<Value>${Variables/CurSize}</Value>
</Attribute>
</Attributes>
위 특성의 일부를 사용하여 열 너비, 맞춤, 정렬 상태 및 스타일을 설정하는 일반 데이터 정의 요소는 다음과 같습니다.
<DataDefinitionElement name="DATE_SHIPPED" base="base_SAPDate">
<Label>Date Shipped</Label>
<Required>false</Required>
<ColumnWidth>400</ColumnWidth>
<ColumnAlignment>right</ColumnAlignment>
<ColumnSorting>Case Sensitive String</ColumnSorting>
<Attributes>
<Attribute>
<Name>style</Name>
<Value>color:red</Value>
</Attribute>
</Attributes>
</DataDefinitionElement>
이 특성은 열 너비를 나타내는 숫자(문자 수)를 사용합니다.
<ControlElementModifiers>
<BuilderCall use_modifier_dataentry="true" use_modifier_display="true">
<BuilderDefID>com.bowstreet.builders.webapp.AttributeSetterBuilderBuilderDefID>com.bowstreet.builders.webapp.AttributeSetterBuilder></BuilderDefID>
<Inputs>
<Input name = "BuilderCallEnabled">true</Input>
<Input name = "HandleExisting">Skip</Input>
<Input name = "HandleMissingValue">Ignore</Input>
<Input name = "Separator">;</Input>
<Input name = "Attributes">
<top>
<Attribute>
<Name>style</Name>
<Value>color:red</Value>
</Attribute>
</top>
</Input>
</Inputs>
</BuilderCall>
</ControlElementModifiers>
<DataEntryControl>com.bowstreet.builders.webapp.TextAreaBuilder</DataEntryControl>
<DataEntryInputs>
<Inputs>
<Input name = "Wrap">off</Input>
<Input name = "Cols">80</Input>
<Input name = "Rows">5</Input>
</Inputs>
</DataEntryInputs>
이 특성은 데이터 항목 제어와 비슷하지만 보기 전용 페이지에 사용됩니다. 빌더의 해당 요소 이름은 <DisplayInputs>입니다.
컨테이너 필드의 추가 값은 다음을 포함합니다.
이 특성을 사용하여 가능한 값 세트가 포함된 필드의 선택사항을 설정할 수 있습니다. 이 특성은 검색 테이블이 제공하는 것과 같은 별도의 텍스트/값으로 제공되지 않습니다.
열거 값의 자국어 지원에 대한 내용은 아래 주를 참조하십시오.
이 특성의 일반적인 사용은 다음과 같습니다.
<EnumerationValues>
<Value>Shipped</Value>
<Value>Out of Stock</Value>
<Value>Returned</Value>
<Value>In Process</Value>
</EnumerationValues>
이 특성을 서식있는 데이터 정의 파일에 추가할 수 있습니다. 이 특성은 유효성 검증에 실패한 필드의 오류 메시지를 대체하는 데 사용되는 문자열을 사용합니다.
이 특성을 사용하여 서식있는 데이터 정의 파일에 사용자 정의 포맷터 클래스를 지정할 수 있습니다. 포맷터 클래스는 데이터 필드 수정자 빌더와 동일한 메커니즘과 인터페이스를 사용합니다.
포맷터 클래스 이름은 아래 표시된 "FormatterClass" 요소를 사용하여 지정됩니다.
<DataDefinition name="AMOUNT" base="base_Currency">
<Label>Amount</Label>
<ColumnSorting>Case Sensitive String</ColumnSorting>
<ColumnWidth>100</ColumnWidth>
<ColumnAlignment>right</ColumnAlignment>
<FormatterClass>com.bowstreet.builders.webapp.pageautomation.StandardFormatter</FormatterClass>
<FormatExpr resource_key="BaseDate_FormatExpr">Format(yyyy-MM-dd$MM/dd/yyyy)</FormatExpr>
<TranslateExpr resource_key="BaseDate_TranslateExpr">Translate(yyyy-MM-dd$MM/dd/yyyy)</TranslateExpr>
<ValidateExpr>Date(yyyy-MM-dd)</ValidateExpr>
</DataDefinition>
StandardFormatter를 클래스의 스펙으로 바꾸십시오. FormatterClass 요소를 제거하면 StandardFormatter 클래스가 사용됩니다.
데이터 정의에 적합한 FormatExpr, TranslateExpr 및 ValidateExpr 요소로 바꾸십시오.
필드의 기본 초기값을 정의하는 데 사용할 수 있습니다. 데이터 필드 수정자 빌더의 초기값 입력을 설정하는 것과 같습니다.
이 특성을 사용하여 검색 테이블을 작성하고 필드와 연관시킬 수 있습니다. 새 검색 테이블을 작성하려면, 빌드의 ID를 지정해야 하고 빌더는 웹 애플리케이션에서 검색 테이블을 작성하는 빌더여야 합니다(검색 테이블, Domino 키워드 검색 또는 SAP 도움말 값). 아래 표시된 Inputs 요소에 필수 빌더 입력을 모두 지정하십시오.
이 예제 코드는 검색 테이블 빌더를 사용하여 XML 데이터에서 검색을 작성합니다. 이 기능은 SAP 도움말 값 검색을 자동으로 작성 및 적용하는 데도 사용되었습니다.
<DataDefinitionElement name="BILLING">
<Label>Billing</Label>
<LookupTable>
<BuilderID>com.bowstreet.builders.webapp.LookupTableBuilder</BuilderID>
<Name>billing</Name>
<Inputs>
<Input name = "DataType">NewXmlData</Input>
<Input name = "GetDataFrom">BuilderInput</Input>
<Input name = "TablePosition">InFront</Input>
<Input name = "Name">billing</Input>
<Input name = "NewXmlData">
<lookup>
<entry>
<name>Purchase Order</name>
<value>1</value>
</entry>
<entry>
<name>Credit Card</name>
<value>0</value>
</entry>
</lookup>
</Input>
<Input name = "ValueElementName">value</Input>
<Input name = "LabelElementName">name</Input>
</Inputs>
</LookupTable>
</DataDefinitionElement>
<PotentialColumnSorting>Case Insensitive String</PotentialColumnSorting>
<DataDefinition name="AMOUNT">
<Label>Amount</Label>
<Properties>
<Property name="ColumnWidth">100</Property>
<Property name="ColumnAlignment">right</Property>
</Properties>
</DataDefinition>
이 특성에서 true 값을 지정하면 필드가 제거됩니다. 필드는 보이지 않고 데이터 열 수정자 또는 데이터 필드 수정자와 같은 기타 빌더에 표시되지 않습니다.
자체적으로 검색을 작성하지 않는 빌더에서 값이 생성되는 경우 검색을 정의하려는 경우 호출에 대한 추가 빌더를 지정할 수 있습니다.
최종 결과는 데이터 정의 파일이 데이터 정의를 참조하는 모든 모델의 필드를 드롭 다운 검색으로 자동으로 채우도록 합니다. 여기서 값은 서비스를 호출하면 자동 검색됩니다. 예를 들어, 다음 XML을 사용하여 서비스 이용자 빌더를 호출하면 검색 값을 동적으로 가져온 후 검색 테이블 빌더에서 결과 값을 참조할 수 있습니다.
<LookupTable>
<Name>companyLookup</Name>
<BuilderID>com.bowstreet.builders.webapp.LookupTableBuilder</BuilderID>
<Inputs>
<Input name = "DataType">XmlData</Input>
<Input name = "VariableType">ValueTagLabelTag</Input>
<Input name = "GetDataFrom">BuilderInput</Input>
<Input name = "TablePosition">InFront</Input>
<Input name = "Name">companyLookup</Input>
<Input name = "XmlData">${MethodCall/companiesGetCompanyList}</Input>
<Input name = "ValueElementName">Value</Input>
<Input name = "LabelElementName">Name</Input>
</Inputs>
<ServiceInfo>
<BuilderID>com.bowstreet.builders.webapp.ServiceConsumer2Builder</BuilderID>
<Inputs>
<Input name = "UseAllOperations">true</Input>
<Input name = "OverrideInputs">false</Input>
<Input name = "Name">companies</Input>
<Input name = "ProviderModel">services/CompanyListService</Input>
<Input name = "OperationName">getCompanyList</Input>
</Inputs>
</ServiceInfo>
</LookupTable>
서식있는 데이터 정의 파일에 필드 그룹을 작성할 수 있습니다.
<DataDefinitions>
<GroupDefinitions>
<GroupDefinition name="Personal">
<Label>Personal Information</Label>
</GroupDefinition>
<GroupDefinition name="Address">
<Label>Address</Label>
</GroupDefinition>
</GroupDefinitions>
<DataDefinition name="Members">
<Required>true</Required>
<Children>
<DataDefinition name="first">
<GroupName>Personal</GroupName>
<Label>First Name</Label>
<Required>true</Required>
<DataType>string</DataType>
</DataDefinition>
<DataDefinition name="last">
<GroupName>Personal</GroupName>
<Label>Last Name</Label>
<Required>true</Required>
<DataType>string</DataType>
</DataDefinition>
<DataDefinition name="states" base="base_US_States">
<GroupName>Address</GroupName>
<Label>States</Label>
<Required>false</Required>
</DataDefinition>
<DataDefinition name="birthdate" base="base_date">
<GroupName>Personal</GroupName>
<Label>Date Of Birth (MM/DD/YY)</Label>
<Required>false</Required>
</DataDefinition>
<DataDefinition name="birthtime" base="base_time">
<GroupName>Personal</GroupName>
<Label>Time Of Birth (HH:MM AM/PM)</Label>
<Required>false</Required>
</DataDefinition>
<DataDefinition name="salary">
<GroupName>Business</GroupName>
<Label>Salary</Label>
<Required>false</Required>
</DataDefinition>
</Children>
</DataDefinition>
</DataDefinitions>
<GroupDefinitions> 요소는 <GroupDefinition> 요소에 따라 필드의 개별 그룹으로 설정됩니다.
서식있는 데이터 정의 파일에서 기본 속성을 사용하여 다른 데이터 정의에서 특성을 상속할 수 있습니다.
예를 들어, 일반 데이터 필드(QUANTITY 및 DATE_ORDERED)에 대한 두 가지 정의는 다음과 같습니다.
<DataDefinitionElement name="QUANTITY">
<Label>Quantity</Label>
<Required>false</Required>
<ValidateExpr>Optional integer</ValidateExpr>
</DataDefinitionElement>
<DataDefinitionElement name="DATE_ORDERED" base="base_SAPDate">
<Label>Date Ordered</Label>
</DataDefinitionElement>
DATE_ORDERED에 대한 정의는 기본 속성의 값에서 파생됩니다. DATE_ORDERED에 사용되는 base_SAPDate 정의는 다음 코드와 같습니다.
<DataDefinitionElement name="base_SAPDate">
<DataEntryControl>com.bowstreet.solutions.wfm.builders.CalendarPickerBuilder</DataEntryControl>
<DataEntryInputs>
<Inputs>
<Input name = "Format">MM/dd/yyyy</Input>
</Inputs>
</DataEntryInputs>
<FormatExpr>Format(yyyy-MM-dd$MM/dd/yyyy)</FormatExpr>
<TranslateExpr>Translate(yyyy-MM-dd$MM/dd/yyyy)</TranslateExpr>
<ValidateExpr>Optional Date(yyyy-MM-dd)</ValidateExpr>
</DataDefinitionElement>
양식 또는 페이지에 현재 표시된 열이나 필드를 숨길 수 있습니다.
열 또는 필드가 현재 표시되지 않은 경우, 양식이나 필드에 표시되도록 할 수도 있습니다. IBM Web Experience Factory의 모델 편집기에서 페이지 및 설계 패널을 사용하여 변경할 양식 또는 페이지를 볼 수 있습니다.
모델에 이 양식이나 페이지에 대한 관련 빌더가 없는 경우 권장 빌더가 모델에 추가됩니다. 이 양식이나 페이지에 대한 관련 빌더가 모델에 있는 경우 해당 빌더의 관련 입력이 변경사항으로 업데이트됩니다.
열을 정렬할 수 있는지 여부를 수정할 수 있습니다.
IBM Web Experience Factory의 모델 편집기에서 페이지 및 설계 패널을 사용하여 변경할 양식 또는 페이지를 볼 수 있습니다.
모델에 이 양식이나 페이지에 대한 관련 빌더가 없는 경우 권장 빌더가 모델에 추가됩니다. 이 양식이나 페이지에 대한 관련 빌더가 모델에 있는 경우 해당 빌더의 관련 입력이 변경사항으로 업데이트됩니다.
여러 개의 필드가 하나의 필드로 표시되도록 병합하거나, 여러 개의 열이 하나의 열로 표시되도록 병합할 수 있습니다.
한 데이터를 여러 필드에 사용해야 하는 경우가 있습니다. 그러나 이 데이터를 표시할 때 이러한 여러 필드가 하나의 열로 표시되도록 하고자 할 수 있습니다. 예를 들어, 어떤 사람의 주소가 시/도, 구/군/시, 우편번호 필드로 구성되어 있을 수 있습니다. 이 경우 데이터 필드 병합 빌더를 사용하여 개별 필드를 세부사항 페이지의 단일 필드 또는 단일 표시 열로 처리할 수 있습니다.
IBM Web Experience Factory의 모델 편집기에서 페이지 및 설계 패널을 사용하여 변경할 양식 또는 페이지를 볼 수 있습니다.
데이터 필드 병합 빌더가 설정과 함께 모델에 추가됩니다. 빌더 호출 편집기를 열고 병합된 필드 사이에 표시될 구분 문자를 지정할 수 있습니다. 빌더 호출 편집기에서 필드를 끌어다 놓아 필드 순서를 재정렬할 수도 있습니다.
다음 단계에 따라 데이터 형식 또는 기타 필드 유형을 변경하십시오.
다음 단계에 따라 재사용할 데이터 정의 파일을 작성하십시오.
IBM Web Experience Factory 모델의 페이지는 모델 외부에서 가져오거나 모델에서 작업할 때 작성될 수 있습니다.
다른 빌더 호출은 페이지가 표시하는 HTML 제어를 수정하거나 추가하여 이들 페이지에서 작동할 수 있습니다.
데이터 페이지를 사용하는 나머지 빌더와 함께 데이터 페이지 빌더는 표시되는 페이지의 HTML을 자동으로 생성할 수 있습니다. 이 기능을 "페이지 자동화"라고 합니다. 페이지 자동화 HTML 템플리트를 사용하여 생성된 HTML의 룩앤필을 제어할 수 있습니다.
자세한 정보 및 실제 애플리케이션에 대한 정보는 이 IBM Web Experience Factory 위키 기사를 참조하십시오.
'이름 지정된 태그' 기술은 세 가지 페이지 위치 메소드 중 가장 단순한 기술이며 빌더 제어를 구현하는 JSP 코드로 페이지의 이름 지정된 요소를 바꾸는 것을 의미합니다.
'이름 지정된 태그' 기술을 사용하여 페이지에 제어 빌더 호출을 배치하려면 다음을 수행하십시오.
페이지에 제어 빌더 호출을 배치할 때 '이름 지정된 태그에 상대적' 기술은 '이름 지정된 태그에서' 메소드보다 조금 더 복잡합니다.
빌더 페이지 위치 입력에서 이름 지정된 태그에 상대적을 사용하는 경우, 이름 지정된 태그의 컨텐츠를 바꾸거나, 지정된 태그 안에 새 태그를 삽입하거나, 이름 지정된 태그 근처에 어떤 방법으로 방향이 지정되는 새 태그를 삽입할 것을 선택할 수 있습니다. 이름 지정된 태그에 상대적 기술을 사용하려면 다음 단계를 수행하십시오.