- 追加された行はこの色です。
- 削除された行はこの色です。
#navi(../../)
* GEF : RetargetAction のしくみ [#x17e22e4]
(書きかけ)
GEF の GraphicalEditor を利用してエディターを作る場合、
削除やアンドゥなどの基本的な処理は ActionBarContributor に対応する RetargetAction を追加するだけで動作します。
しかし、それぞれの RetargetAction 実装クラスのソースを見ても
実際の挙動は書いてありません。
プラグイン全般のリターゲットアクション同様、ID を提供するだけです。
GEF に限らず、リターゲットアクションは ID を提供するだけで、
実際に個別のエディターやビューが、ID に対応する実際の Action を提供します。
では、アクションの実際の処理はどこに記述されているのでしょうか。~
たとえば削除を処理する Action であれば、
選択されたフィギュアに対応する EditPart に
RequestConstants.REQ_DELETE のタイプを持つ Request を投げているはずです。
** 実 Action [#i479e161]
実際に処理を行う Action は、org.eclipse.gef.ui.actions パッケージ内に WorkbenchPartAction を継承したクラスとして用意されています。
たとえば削除を処理する DeleteAction は、
createDeleteCommand() メソッドの中で
+ 選択されている(フィギュアに対応する)EditPart を取得し
+ EditPart#getCommand(Request) メソッドに REQ_DELETE の Request を渡して command を取得
(実際には EditPart にインストールされている EditPolicy が command を生成しているはず)
という順序で command を生成し、
run() メソッドでこの command を(スタックを使って)実行します。
** 実 Action はどこで登録されるか [#a2e3be6d]
GraphicalEditor を継承してエディターを作成する場合、
DeleteAction のような Action 本体をわざわざ生成したり、登録する必要はありません。~
これらの処理は GraphicalEditor の createAction() メソッドで行われています。
このメソッドの中で
+ Action クラスの生成
+ GraphicalEditor の ActionRegistry への追加
+ Action の種類ごとに、GraphicalEditor の持っている Action ID リストへの追加
を行っています。~
を行っています。
3つめの Action ID リストは3種類あって、
Action の内容に応じて stackActions, selectionActions, propertyActions のいずれかに追加しています。
(どのリストにも追加しなくともよいようです。
たとえば PrintAction は上記 1, 2 しか行っていません)
** 実 Action [#i479e161]
実際に処理を行う Action は、org.eclipse.gef.ui.actions パッケージ内に WorkbenchPartAction を継承したクラスとして用意されています。
たとえば削除を処理する DeleteAction は、
createDeleteCommand() メソッドの中で
+ 選択されている(フィギュアに対応する)EditPart を取得し
+ EditPart#getCommand(Request) メソッドに REQ_DELETE の Request を渡して command を取得
(実際には EditPart にインストールされている EditPolicy が command を生成しているはず)
という順序で command を生成し、
IAction#run() をオーバーライドした run() メソッドでこの command を(スタックを使って)実行します。
** RetargetAction は何の処理を担っているのか [#nbb95c6a]