The Outline view is not generated by the editor framework. In fact, this view is offered by the org.eclipse.ui.views plug-in. When the user changes editors, your editor will be asked to provide an IContentOutlinePage adapter for an Outline view. This is how you should implement your outline viewer:

Outline View는 Editor Framework에 의해 생성되지 않는다. 사실 이 View는 org.eclipse.ui.views의 plug-in에 의해 제공된다. 

사용가 에디터를 변경할 때, 너의 에디터는 Outline View를 위한 IContentOutlinePage 어탭터를 제공할 지 물을 것이다. 이것은 어떻게 너의 outline viewer를 구현해야만 하는지이다.

In plugin.xml, define an adapter for your editor to content outline page:

plugin.xml 에 outline page contents로 editor를 위한 adapter를 정의한다.

<extension point="org.eclipse.core.runtime.adapters">
  <factory
    adaptableType="org.acme.editor.CoolLanguageEditor"
    class="org.acme.editor.CoolLanguageEditorToOutlineAdapterFactory">
    <adapter type="org.eclipse.ui.views.contentoutline.IContentOutlinePage"/>
  </factory>
</extension>

and the Java code

public class CoolLanguageEditorToOutlineAdapterFactory implements IAdapterFactory {
   @Override
   public Object getAdapter(Object adaptableObject, Class<?> required) {
      if (IContentOutlinePage.class.equals(required)) {
            CoolLanguageEditor editor = (CoolLanguageEditor)adaptableObject;
            return new CoolLanguageContentOutlinePage(...);
         }
      }
   }
 
   @Override
   public Class<?>[] getAdapterList() {
      return new Class<?>[] { IContentOutlinePage.class };
   }
}

Most programming languages are inherently hierarchical. Therefore, to show the content outline of a certain program file, most editors deploy a tree. If you think that a tree is the most appropriate way to show the outline of your programs, you should consider subclassing from class ContentOutlinePage in the org.eclipse.ui.views.contentoutline package. This class already sets you up with a TreeViewer, and all you need to provide are a content provider, a label provider, and the input:

대부분의 프로그래밍 언어는 원래 계층구조이다. 그러므로 확실한 프로그램 파일의 content outline 을 보여주기 위해서는 대부분의 editor가 트리로 배포되어야 한다. 만약에 너의 프로그램의 outline을 보여주기 위한 가장 적절한 방법이 트리구조라고 생각한다면, 너는 org.eclipse.ui.views.contentoutline 패키지 안에 ContentOutlinePage 클래스를 상속받는 것을 고려해야한다.

이 클래스는 이미 TreeViewer로 set up 하고 너가 필요한 모든 것이 content provider, label provider이고 다음을 입력한다.

   public void createControl(Composite parent) {
      super.createControl(parent);
      TreeViewer viewer= getTreeViewer();
      viewer.setContentProvider(new MyContentProvider());
      viewer.setLabelProvider(new MyLabelProvider());
      viewer.addSelectionChangedListener(this);
      viewer.setInput(myInput);
   }

You will want to update the selection in your Outline view when the cursor is moved in the editor. Similarly, if the structure of the program changed—code added or removed—the outline has to be updated. This is typically performed with a JFace text model reconciler.

너는 커서가 에디터로 이동할 때, Outline View에서 selection을 갱신하길 원할 것이다. 비슷하게 만약 코드가 추가, 삭제되는 것으로 인해 프로그램 구조가 변하면, outline도 update될 것이다. 이것은 JFace text model의 전형적인 수행방식이다.

When the user selects a node in the Outline view, the editor should change selection to the selected element and make it visible.

사용자가 Outline view에 노드를 선택하면, 에디터는 선택된 요소로 selection을 변경하고 그것을 보여주게 한다.

When https://bugs.eclipse.org/bugs/show_bug.cgi?id=507205 is fixed, a recommended way would be to rely on the Common Navigator Framework in order to implement Tree-based navigation outline pages. For the moment, you can already write your own outline view consuming the CommonViewer class.

   public void createControl(Composite parent) {
      CommonViewer viewer = new CommonViewer(ID, parent, SWT.V_SCROLL | SWT.H_SCROLL);
      viewer.setInput(myInput);
   }

With ID being the name of the common navigator defined in org.eclipse.ui.navigator.viewer extension. Then the outline should receive most features as expected by the common navigator framework. This approach allows a better refactoring as multiple viewers can very easily share some common parts.