이 섹션에서는 3.1 메커니즘 및 API를 채택하도록 3.0 플러그인을 변경하려는 경우 필요한 변경사항에 대해 설명합니다.
Eclipse 3.1은 실행, 실행 취소 및 다시 실행한 조작의 트랙을 유지하는 공유 조작 히스토리와 실행 취소할 수 없는 조작을 정의하기 위한 새 하부구조를 제공합니다. 부가 기능 플러그인이 제공하는 다양한 실행 취소 프레임워크를 시간이 지나 플랫폼 조작 지원으로 이주하여, 프레임워크 클라이언트가 더 깊이있게 플랫폼과 통합하고 다른 플러그인 보기 및 편집기에서의 실행 취소에 해당되는 실행 취소 가능 조작을 사용할 수 있도록 만들어야 합니다. 플러그인에 실행 취소 지원을 추가하는 방법에 관한 기본적인 정보는 실행 취소 가능한 조작 문서를 참조하십시오. 이미 실행 취소 지원을 정의하거나 다른 프레임워크를 사용하는 플러그인은 아래에 설명된 대로 단계화된 형태로 새 실행 취소 지원으로 이주할 수 있습니다.
이미 실행 취소 가능한 조작을 설명하는 클래스를 정의한 플러그인은 인터페이스 IUndoableOperation에 대한 구현을 해당되는 조작/명령 클래스에 추가해야 합니다. 플러그인은 필요할 경우 계속해서 이전 프레임워크로 히스토리(명령 스택)를 관리하지만 IUndoableOperation용 인터페이스를 제공하여 플러그인의 클라이언트가 플랫폼 조작 히스토리에 있는 것과 같은 조작을 사용하고 다른 플러그인의 실행 취소 가능 조작과 혼합하여 일치되도록 할 수 있습니다. 이 전략은 새 조작 프레임워크로 이주하기 위해 SDK 텍스트 편집기가 사용하는 전략과 유사합니다. 인터페이스의 직접적 맵핑이 가능하지 않을 경우, 랩퍼를 사용하여 IUndoableOperation 프로토콜을 레거시 실행 취소 오브젝트에 맵핑할 수 있습니다. 이 전략은 플랫폼/JDT 리팩토링 지원에서 사용합니다. 조작/명령 클래스를 IUndoableOperation으로 이주하는 것은 중요한 단계입니다. 이렇게 이주하면 플러그인이 완전히 이주하지 않아도 다른 프레임워크의 실행 취소 가능 조작을 다른 플러그인에서 활용할 수 있기 때문입니다.
실행 취소 가능 조작 또는 명령이 IUndoableOperation 관점에서 표시되면, 실행 취소 가능 및 다시 실행 가능 조작의 트랙을 유지하기 위해 실행 취소 히스토리(명령 스택)를 정의하는 플러그인은 해당되는 실행 취소 히스토리를 표시하는 IUndoContext를 정의하여 플랫폼 조작 히스토리로 이주할 수 있습니다. 이전에 로컬로 관리했던 실행 취소 히스토리는 모델 오브젝트마다 또는 파트마다 고유한 실행 취소 컨텍스트를 정의하고, 각 조작에 적절한 실행 취소 컨텍스트를 추가한 후 조작을 플랫폼 조작 히스토리에 추가하여 공통 조작 히스토리에 병합될 수 있습니다. 범위가 더 광범위한 실행 취소 히스토리는 해당되는 실행 취소 범위를 표시하는 고유한 실행 취소 컨텍스트를 정의한 후 해당 컨텍스트를 각 조작에 지정하고 조작을 플랫폼 조작 히스토리에 추가하여 구현할 수 있습니다. 실행 취소 컨텍스트를 작성하고 지정하고 조작을 플랫폼 조작 히스토리에 추가하는 예제를 보려면 실행 취소 가능 조작 문서를 참조하십시오.
네비게이터나 패키지 탐색기와 같은 Workbench 보기에서 해당 조작이 실행 취소 가능하도록 하려는 플러그인은 Workbench 실행 취소 컨텍스트를 해당 조작에 지정해야 합니다. 이 실행 취소 컨텍스트에 대한 자세한 정보와 Workbench 및 헤드없는 플러그인 둘 다에서 이 컨텍스트를 검색할 수 있는 방법에 관한 정보는 실행 취소 가능 조작 문서를 참조하십시오.
실행 취소 인프라스트럭처나 실행 취소 가능 조작을 정의하지 않지만 플랫폼의 실행 취소 히스토리에 대한 액세스 권한은 제공하려는 플러그인의 경우 새로운 공통 실행 취소 및 다시 실행 조치 핸들러를 사용하여 글로벌 실행 취소 및 다시 실행 조치 핸들러의 대상을 다시 지정할 것을 고려해야 합니다. 조치 핸들러에는 표시될 실행 취소 및 다시 실행 히스토리를 지정하는 실행 취소 컨텍스트를 지정해야 합니다. 플러그인은 "파트-로컬" 실행 취소 및 다시 실행 히스토리를 표시하기 위해 로컬로 정의된 실행 취소 컨텍스트를 사용할 수 있습니다. Workbench 전반의 실행 취소 및 다시 실행 히스토리를 표시하기 위해 Workbench 실행 취소 컨텍스트를 사용할 수 있습니다. 실행 취소 가능 조작 문서에 자세한 예제가 있습니다.
문서 편집기 실행 취소 및 다시 실행 조치를 이주하는 것은 단지 글로벌 실행 취소/다시 실행 조치 핸들러의 대상을 다시 지정하는 것보다 약간 어렵습니다. AbstractTextEditor 프레임워크는 매개변수화된 TextOperationAction을 사용하여 공통 텍스트 조치를 정의합니다. 이 조치는 프레임워크에 로컬로 저장되며 편집기의 텍스트 조작 대상에 다양한 명령을 디스패치하기 위해 사용됩니다. 텍스트 실행 취소가 적절하게 작동되도록, 문서 편집기 프레임워크는 적절한 ID(ITextEditorActionConstants.REDO 및 ITextEditorActionConstants.UNDO)를 가지고 있는 텍스트 조작 조치의 존재 여부에 의존합니다.
AbstractTextEditor가 공통 조치 핸들러를 작성하도록 이주되었지만, 여전히 레거시 ID를 사용하여 TextOperationAction 테이블에 공통 조치 핸들러를 지정합니다. 이 경우 새 실행 취소 및 다시 실행 조치 핸들러는 조치를 검색하고 조작을 수행하기 위한 레거시 기술을 사용하여 검색할 수 있습니다. AbstractTextEditor 계층 구조의 문서 편집기는 이 동작을 상속합니다.
AbstractTextEditor로부터 이 동작을 상속하지 않는 편집기는 기존의 실행 취소 및 다시 실행 조치를 이주하여 새 핸들러를 사용할 것을 고려해야 합니다. 레거시 실행 취소 및 다시 실행 TextOperationAction이 있는 편집기에 대해서는 계속해서 로컬 실행 취소 지원이 작동합니다. 조치에서 사용하는 JFace 텍스트 실행 취소 관리자 API가 계속 지원되기 때문입니다. 그러나 실행 취소 및 다시 실행 조치 레이블은 새 Eclipse SDK 실행 취소/다시 실행 조치와 일치하지 않습니다. 새 Eclipse SDK 실행 취소/다시 실행 조치는 사용 가능한 실행 취소 또는 다시 실행 조작의 이름을 표시합니다. 공통되는 실행 취소 및 다시 실행 조치 핸들러를 작성하려면 조치 핸들러 작성 시 텍스트 표시기의 실행 취소 관리자가 사용하는 실행 취소 컨텍스트를 사용해야 하고 해당되는 핸들러는 적절한 ITextEditorActionConstants ID를 사용하여 편집기에 설정되어 있어야 합니다. 자세한 예제는 AbstractTextEditor.createUndoRedoActions() 및 AbstractTextEditor.getUndoContext()를 참조하십시오. 편집기의 조치 막대에 추가하기 위해 EditorActionBarContributor 서브클래스에 의존하는 편집기는 실행 취소 및 다시 실행 조치 핸들러를 작성하고 활성 편집기 설정 시 이 핸들러를 설정하여 유사한 기술을 사용할 수 있습니다.
검색 페이지를 검색 대화 상자에 제공하는 플러그인은 가지고 있는 모든 정보 스타일 검색을 연합 검색 엔진으로 이식할 것을 고려해야 합니다. 3.1 이후로, 모든 정보 스타일 검색은 Workbench 아티팩트 검색과 구분됩니다. 정보 검색 엔진은 배경 작업과 새 도움말 보기에 배열되는 결과와 병렬로 실행됩니다. 세부사항은 도움말 검색을 참조하십시오.
새로운 동적 도움말 보기는 Workbench 파트 및 대화 상자의 위지트(widget)와 정적으로
연관되는 기존 컨텍스트 ID에 대해 작동합니다. 그러나 도움말 이벤트를 사용자 스스로 발견하여
도움말을 표시할 경우 동적 도움말 보기는 어떤 것도 유용하게 표시할 수 없습니다.
문제점을 수정하려면 동적 컨텍스트 도움말
문서에 설명된 대로 새
IContextProvider
인터페이스를 채택해야 합니다.