Workbench는 복잡한 사용자 인터페이스를 빌드하기 위해 다양한 세트의 클래스와 인터페이스를 제공합니다. 다행히 간단한 작업을 수행할 경우에는 이 모든 사항을 이해할 필요는 없습니다. 우선 먼저 Workbench 사용자 인터페이스와 해당 구조에 나타난 일부 개념을 살펴보겠습니다.
지금까지는 "플랫폼을 시작할 때 열리는 창"을 나타낼 때 Workbench라는 용어를 사용해 왔습니다. Workbench를 구성하는 비주얼 컴포넌트에 대해 좀 더 자세히 살펴보겠습니다.
이 설명의 나머지 부분에서 Workbench라는 용어를 사용할 때는 Workbench 창(IWorkbenchWindow)을 가리킵니다. Workbench 창은 Workbench의 최상위 레벨 창입니다. 이 창은 메뉴 표시줄, 도구 모음, 상태 표시줄, 바로 가기 표시줄 및 페이지 등이 있는 프레임입니다. 일반적으로 Workbench 창에 프로그램할 필요는 없습니다. Workbench 창이 표시된 것만 확인합니다.
참고: 여러 Workbench 창을 열 수 있습니다. 그러나 각각의 Workbench 창은 편집기 및 보기의 독립적인 영역이므로 하나의 Workbench 창에만 초점을 지정합니다.
사용자의 관점에서 Workbench에는 보기와 편집기가 포함되어 있습니다. Workbench 창을 구현하는 데 사용되는 소수의 클래스도 있습니다.
Workbench 창에서 여러 파트를 차례로 포함한 하나의 페이지 (IWorkbenchPage)를 발견할 수 있습니다. 페이지는 파트를 그룹화하기 위한 구현 메커니즘입니다. 대개는 페이지에 대해 프로그램할 필요는 없지만 프로그래밍과 디버깅 컨텍스트에서 페이지를 볼 수 있습니다.
Perspective는 Workbench 페이지에서 조직의 추가 레이어를 제공합니다. Perspective는 지정된 사용자 타스크에 적용 가능한 조치, 보기, 레이아웃의 적절한 콜렉션을 정의합니다. 사용자는 타스크에서 이동하면서 Perspective 사이를 전환할 수 있습니다. 구현 관점에서 활성 Perspective는 Workbench 페이지에 표시되는 보기, 위치 및 크기를 제어합니다. 편집기는 Perspective의 변경사항에 영향을 받지 않습니다.
보기 및 편집기는 구현 세부사항 이외에도 공통 플러그인 프로그래밍을 진행하는 장소입니다. Workbench에 비주얼 컴포넌트를 추가할 경우 보기나 편집기를 구현 여부를 결정해야 합니다. 그 결정 방법에 대해 알아 보겠습니다.
어느 경우든 공통 라이프 사이클에 따라 보기나 편집기를 빌드하게 됩니다.
이 라이프 사이클 동안 해당하는 당사자에게 보기 및 편집기의 열기, 활성화, 비활성화, 닫기를 알려주기 위해 이벤트를 포함하는 Workbench 페이지에서 이벤트를 발생시킵니다.
지금까지 Workbench 보기와 편집기에 대한 설명이 간단해 보일 수 있습니다. 이것이 바로 Workbench 보기와 편집기의 장점입니다. 이들은 단순히 위지트(widget) 홀더일 뿐이고 필요한 대로 간단하거나 복잡해질 수 있습니다. 이전에 Hello World 보기를 빌드할 때 가장 간단한 보기만 보았습니다. 학습 내용을 자세히 설명했으므로 이제 이를 다시 살펴 보겠습니다.
package org.eclipse.examples.helloworld; import org.eclipse.swt.widgets.Composite; import org.eclipse.swt.widgets.Label; import org.eclipse.swt.SWT; import org.eclipse.ui.part.ViewPart; public class HelloWorldView extends ViewPart { Label label; public HelloWorldView() { } public void createPartControl(Composite parent) { label = new Label(parent, SWT.WRAP); label.setText("Hello World"); } public void setFocus() { // set focus to my widget. For a label, this doesn't // make much sense, but for more complex sets of widgets // you would decide which one gets the focus. } }
createPartControl(parent) 메소드에 레이블을 만드는 것외에는 아무 것도 하지 않았기 때문에 dispose() 메소드를 구현할 필요가 없었습니다. 이미지나 글꼴같은 UI 자원을 할당했다면 여기서 삭제해야 합니다. ViewPart 클래스를 확장했기 때문에 dispose()의 "do nothing" 구현을 상속합니다.