blog*witch

I don’t know about relationship between Tibet and China enough well. Anyway Chinese attacked people of my Nation, And they made one little girl cry at least. The Olympic is already failed. There is no peace and love. They don’t understand what Olympic is.

I can understand, the demonstration which talks about the independence of Tibet was something wrong. Because Olympic can’t be used any political purpose. But they choose peaceful way.

People who use violence to keep their benefits don’t have any right to anything. China must punish them to restore own honer of Nation. They just made dirtier themselves and their Nation. For now, I am the one of people who agreeing the independence of Tibet.

Remember,

Love, and be loved one.

이 문서는 wiki.eclipse.org 의 Command and Action 문서를 번역한 것입니다.

Command와 Action은 같은 대상에 대한 두가지 접근법이다. Command는 선언적 - plugin-manifest에서 기술되는 - 부분이고, Action은 프로그래밍적인 부분이라고 생각해도 좋다. Command는 보통 액션에 바로가기 키를 바인딩하기 위해 사용된다. Preference Page에서 Workbench > Key를 선택 해 보면,플랫폼에 알려져 있는 모든 Command 들을볼 수 있다. 키 바인딩은 Command에 의해 후킹되고, Command는 Action들에게 후킹된다. 이 특별한 간접적 계층은 구현에 있어서 좀더 많은 유연성을 부여한다. 사용자는 Action에게 그 사실을 알릴 필요 없이 바로가기 키를 변경할 수 있다. 그리고 Command에 대한 Action역시 키 바인딩에 아무런 영향도 주지 않고, 동적으로 바뀔수 있다.

비록 이클립스 API가 command와 action을 모두 가지고 있지만, UI는 명확하게 Command라는 용어만을 사용한다. Action이라는 용어는 UI에서 사용되지 않는다. 따라서 최종 사용자가 이 둘의 이름때문에 혼동할 일은 없다.

• http://wiki.eclipse.org/ 에서 원문 보기

2/28/2008 추가

이클립스 기여자 폴 웹스터에 따르면, Action은 구식 방식이라고 한다. 사실 Action은 JFace에 있던 개념이 거의 그대로 이클립스에 옮겨 온 것에 불과하다. 가능하면 Command를 이용하는 습관을 가지는 것이 좋을 듯 하다.

이 문서는 이클립스 도움말 중 Plug-ins and bundles를 번역한 것입니다.

플러그인을 지원하는 기술들은 OSGi 프레임 워크를 이용하여 구현되었다. 이러한 관점에서, 플러그인은 OSGi Bundle과 동일한 것이다. Bundle과 그에 연관된 클래스들이 클래스로딩, 관리 그리고 bundle의 수명주기에 관한 문제들을 구체화 하고 구현한다. 이후로, 프레임워크의 특정한 클래스를 언급하지 않는 이상 plug-in과 bundle을 동일한 용어로서 사용하겠다.

Plugin

Plugin 클래스는 플랫폼에서 수행되는 plug-in을 대표한다. 이 클래스는 Plug-in 전반의 관심사나 수명주기와 같은 문제를 모아두기 편리하다. Plug-in은 수명주기를 다루기 위해 특화된 start와 stop 기능을 구현할수 있다. 각각의 수명 주기메소드는 추가적인 정보를 제공할수 있는 BundleContext 객체의 레퍼런스를 가지고 있다.

생명 주기의 시작부분은 따로 논의할만한 가치가 있다. Plug-in의 manifest 파일을 접근함으로써 plug-in의 어떠한 코드도 수행하지 않아도 Plug-in을 얻을 수 있다. 일반적으로 워크밴치의 몇몇 사용자 액션들은 플러그인의 시작을 필요로 하는 연계적 이벤트를 일으킨다. 구현관점에서, plug-in은 plug-in을 구성하는 클래스들 중 하나가 로드되기 전까지 시작되지 않는다.

Start 메소드는 초기화와 등록들과 같은 코드를 넣기 좋은 곳이다. 하지만 plug-in이 다양한 상태에서 시작될 수도 있다는 것을 알아두는 것은 매우 중요하다. 객체를 데코레이트하기 위해 아이콘을 얻는 간단한 작업이 플러그인의 특정 클래스를 로드한다면, 이것이 plug-in을 시작시킨다. 강한 초기화는 플러그인의 코드와 데이터가 필요하기도 전에 로딩을 시작하는 문제를 야기할수 있다. 따라서, 플러그인 초기화 작업은 모든 대안을 면밀히 고려하는 것이 중요하다.

• Registration : 리스너를 등록하거나 백그라운드 스레드를 시작하는 등과 같은 작업은 이들이 빠르게 수행될 수만 있다면 plug-in이 시작될 때 처리하는 것도 좋다. 하지만 등록작업이 대용량의 데이터를 초기화 하거나별 연관성 없는 작업을 수행하는등의 부작용을 가지고 있다면, 이러한 작업을들 접근 부분으로 돌리는 것이 현명하다.
• Initialization : 데이터의 초기화는 데이터가 처음으로 억세스될때 까지 가능한한 미루는 것이 좋다. 이것은 대용량의 데이터가 정말 필요로되기 전까지 만들어지지 않는 것을 보장한다.

Bundle Context

생명주기 관리는 OSGi의 “bundle”이라는 용어와 플랫폼의 “plug-in”이란 용어가 만나는 곳이다. Plug-in 이 시작될 때, plug-in 정보를 얻을 수 있는 곳 (plugin.xml) 으로 부터 plug-in 에 대한 레퍼런스를 BundleContext에게 부여하게 된다. BundleContext는 시스템 안의 다른 번들/플러그인을 찾는데 쓰일 수도 있다.

시스템의 모든 Bundle의 배열을 얻기 위해 BundleContext.getBundles()을 이용할 수 있다. Bundle의 생명 주기 변화를 감지하고 대처하기 위해 BundleEvent에 대한 리스너를 부착할 수도 있다. 추가 정보를 얻기 위해, BundleContext 와 BundleEvent에 대한 javadoc을 읽어보라.

3.0 이전의 버전에서는, plug-in registry (IPluginRegistry)가 이와 유사한 기능들을 제공하기 위해서 사용되었다. 예를 들어 모든 플러그인을 얻기 위한 쿼리와 같은 것이 있다. 현재 이 registry는 deprecate 되었고, BundleContext 가 이 기능을 대신한다. Platform registry는 현재 확장과 확장점에 대해 배타적으로만 사용된다.

Bundle Activator

BundleActivator 인터페이스는 Plugin 에서 구현된 시작과 정지를 정의한다. Plugin 클래스가 이를 구현하기에 적합한 곳이기는 하지만, 개발자는 BundleActivator 인터페이스에 대한 구현을 plug-in 의 디자인에 맞추어 아무곳이나 자유롭게 할수 있다. 사실, 특별한 생명주기 관리 매커니즘이 필요없다면 plug-in 이 굳이 이를 구현해야할 필요도 없다.

Bundles

모든 plug-in들이 프레임워크가 관리하는 OSGi bundle을 기반으로 한다. Bundle은 OSGi 의 모듈화 단위이다. 본질적으로 Bundle 은 플랫폼에 설치된 단순한 파일의 집합이다. (리스스와 코드) 각각의 Bundle은 고유 자바 클래스 로더를 가지고 있고, 시작 정지 그리고 언인스톨에 대한 프로토콜들을 포함한다.이클립스 플랫폼이라는 관점에서 Bundle은 단지 구현 클래스일 뿐이다. Plug-in 개발자들은 Bundle을 확장하지 말고, Plugin 이나 BundleActivator 구현을 이용해서 Plug-in을 대표하면 된다.

• 원문: 이클립스 3.3 도움말

개요

Eclipse는 워크벤치 어드바이저에 다음과 같은 코드를 추가함으로써, 간단하게 레이아웃 및 윈도우 설정을 퍼시스트 할 수 있다:

configurer.setSaveAndRestore(true);

이거야 뭐 대부분의 이클립스 입문서에서 다루는 이야기라 아는 이야기지만 진취적인 개발자라면 여기서 의문이 생겨나야 한다. 레이아웃은 페이지와 페이지에 담긴 뷰와 에디터들의 배치를 담당하고 있다.이 정보가 보존된다면, 이클립스를 다시 시작할때 마다 어떤 뷰와 에디터들을 보여줘야할지 결정할 수 있을 것이다. 하지만 뷰와 에디터들의 상태는 어떻게 되는가? 뷰나 에디터에는 개발자가 직접 추가한 필드나 하위 컨트롤들이 있을 것이다. 이들의 상태는 어떻게 되는가?

결론 부터 말하자면 모조리 날아가버린다. 뷰와 에디터의 배치는 복구되지만 뷰와 에디터의 상태는 복구되지 않는다. 보존한 적도 없고, 보존하는 코드를 작성한 적도 없으니 당연한 결과이다. 앞으로 뷰를 기준으로 설명해 나가겠다.

어디에 뷰의 상태를 보존하는 코드를 삽입해야 하는가?

이클립스 플랫폼은 IViewPart에 제공하는 다음 두 메소드로 상태의 보존과 복구를 제공한다:

• public void saveState(IMemento)
  현재 뷰의 상태를 메멘토에 보존한다.
• public void init(IViewSite, IMemento) throws PartInitException
  현재 뷰의 상태를 메멘토로 부터 복구한다.이 메소드는 createPartControls() 보다 먼저 호출된다는 점을 주의해야 한다.

따라서 이 두 메서드를 오버라이드 하는 것만으로도 당신의 뷰는 자동적으로 상태를 기억하고 보존할 수 있게 된다.

메멘토가 뭔가?

단기 기억 상실증을 다룬 영화를 떠올리고 계신 분들이 많으시리라 예상 되는 대목이다. 메멘토는 직역 하면, 기억, 추억 또는 유물등으로 해석할 수 있다. 거참 멋진 용어를 선택하셨구랴 IBM양반들♥

메멘토는 데이터를 보존하기 위한 공간이긴 하지만, 하이버네이트나 iBATIS 처럼 주 컨텐츠로서 데이터를 보존하는 공간이 아니라, 온갖 잡스러운 “기억꺼리”를 보존하는 도구이다. 예를 들면, 사용자가 선택해둔 사항이나, 열려있는 뷰나, 뷰의 소팅 옵션이나 필터 설정들과 같은 잡다한 정보들 말이다.

메멘토는 이클립스 워크벤치에 의해 관리되며 필요한 곳에 준비된 형태로 공급된다. 따라서 개발자는 메멘토가 어디에 보존되는지, 메멘토 도구를 어떻게 얻어올 것인지를 신경 쓸 필요가 없다. 메멘토는 자동으로 관리되는 문맥을 가지고 있기 때문에, 사용할때, 다른 곳에서 같은 이름으로 데이터를 보존했는가 여부를 고민할 필요도 없다. 사용법은 해쉬맵과 거의 동일하다. 주로 사용되는 메서드는 다음과 같다:

• public void putString(String key, String value);
  특정 키에 String 값을 넣는다.
• public String getString(String key);
  특정 키의 값을 스트링으로 얻어온다. (Float과 Integer도 마찬가지 형태로 get/put이 제공된다.)
• createChild(String)
  하위 문맥을 확장한다.
• getChild(String)
  하위 문맥을 얻어온다.

메멘토는 워크밴치가 종료될때 알아서 XML형태로 보존된다. 워크스페이스 경로 / .metadata / .plugins / org.eclipse.ui.workbench 에 들어가보면 workbench.xml 파일이 있는 데, 이 파일을 보면 메멘토가 어떻게 보존되는지 쉽게 확인 할 수 있다. 메멘토는 원래 잡다한 것을 저장하는 도구이고, XML로 보존되기 때문에 객체나 복잡한 데이터를 저장하는 데에는 적합하지는 않다.