覚書ブログ

2010年2月8日月曜日

EMFValidationの翻訳

使えるかと思うので翻訳をしてみました。
あとでちゃんと直します。

The validation framework provides support for constraint providers for any EMF meta-model (batch and live constraints), customizable model traversal algorithms, constraint parsing for languages, configurable constraint bindings to application contexts and validation listeners. The following are the main extension points and classes to be used with the validation framework.

ValidationFrameworkは以下のような制約プロバイダのサポートを提供する。
EMFメタモデル、モデルトラバーサルアルゴリズム、言語の制約パース、アプリケーションコンテキスト、validation リスナのバインディング制約などである。
次のようなvalidationFrameworkを使ったクラスや拡張ポイントがある。

1.The extension point org.eclipse.emf.validation.constraintProviders is used to provide constraints. Static constraint providers declare constraints in the plugin.xml. Constraints are grouped into hierarchically structured categories. Constraint providers target one or more EPackages by namespace URI. A group of constraints declares categories in which they are members. Each constraint has a variety of meta-data associated with it (Language, ID, severity, mode, name, message, triggers, etc.). Dynamic constraint providers address situations where constraints cannot be declared statically. e.g., where constraints are defined in models or other resources. Dynamic providers declare a class implementing the IModelConstraintProvider interface. This class is responsible for making constraints available on the appropriate triggers, organizing them into categories, etc.

拡張ポイントorg.eclipse.emf.validation.constraintProvidersで制約を与えることができる。
静的な制約はplugin.xmlで宣言をすることができる。
制約は構造化されたカテゴリに階層的にグループ化することができる。
制約プロバイダは１つのターゲットや名前空間URIのEPackageをターゲットにすることができる。
制約グループはメンバーのカテゴリを宣言する。
各々の制約はそれに関連するメタデータに種類を持つ。
（言語、ID,severity,mode,name,message,triggers)
次に動的な制約は静的に制約が定義できない場合に使われる。
制約はモデルや他のリソースで定義される。
動的な制約プロバイダはIModelConstraintProviderインタフェースを実装したクラスで
定義できる。
このクラスは適当なトリガや、カテゴリに組み込む制約を有用化する責任をおう。

2.The extension point org.eclipse.emf.validation.traversal is used to provide customizable model traversal algorithms. Batch validation traverses a subset of the model starting from the user's selections. No traversal is performed in live validation. Some meta-models require custom strategies for traversal. The default strategy simply iterates the content tree via eAllContents() API. Some meta-models do not use EMF containment relationships extensively, or implement logical models on multiple distinct resources, making containment-based traversal impractical.

拡張ポイントorg.eclipse.emf.validation.traversalはモデルトラバーサルなアルゴリズムで使用する。
バッチvalidationはユーザの選択したモデルのサブセットを横断する。
live validationはモデルの横断はできない。
トラバーサルには独自ロジックが必要となる。
デフォルトのロジックはeAllContents() APIを通してコンテンツツリーを走査する。
メタモデルはEMF Containment関係を使わない。
または、または多重の区別するリソースについてモデルや実用的なコンテナベースの横断を
持ったモデルを実装する。

3.The extension point org.eclipse.emf.validation.constraintParsers is used to provide constraint parsing for languages. The validation framework provides support for two languages: Java and OCL. Clients can provide support for other constraint languages via constraint parsers. The Language ID: used in the lang attribute of constraint elements in the constraint XML. The Class: identifies an implementation of the IXmlConstraintParser interface, which constructs a constraint from the XML configuration data. Constraint parsers are responsible for parsing the content of a constraint element in the plugin.xml to produce IModelConstraint objects.

拡張ポイントorg.eclipse.emf.validation.constraintParsersは言語の制約パースに対して使われる。
validation frameworkは2つの言語(Java OCL)で利用される。
クライアントは制約パーサを通して他の制約言語に対するサポートを提供できる。
言語ID：制約XMLの中の制約の要素の属性で使われる。
クラス：IXｍｌConstraintParserインタフェースで実装された識別
XMLの設定ファイルからの制約で作成された。
制約パーサはIModelConstraintを作るためのplugin.xmlに記述された
制約要素のコンテンツをパースするのに使われる。

4.The extension point org.eclipse.emf.validation.constraintBindings allows clients of the EMF Validation framework to define "client contexts" that describe the objects that they are interested in validating, and to bind them to constraints that they are interested in enforcing on these objects. A client context can declare an enablement expression that matches model elements that are included in the context. Where that is not sufficient, an alternative is to define a selector class using a selector element. Client contexts can be bound to constraints, individually, or to constraint categories (to bind all of the constraints in the category). Binding to constraint categories has the advantage of allowing new constraint contributions in a category to automatically be bound to the appropriate client context, even if the constraint is defined in a plug-in that is unaware of that context or its binding to the category. Category bindings are inherited by sub-categories from their ancestors.

拡張ポイントorg.eclipse.emf.validation.constraintBindingは
EMFValidationフレームワークのクライアントが"クライアントコンテキスト"を定義できる。
クライアントコンテキストはvalidationで興味があるオブジェクトを記述する。
オブジェクトに対して実施することに興味がある制約に対してバインドする。
クライアントコンテキストはコンテキストの中にあるモデル要素にマッチした可能な表現
で定義する。
十分でない場合、オルタネイティブはセレクタ要素を使ってセレクタクラスを定義すべきである。
クライアントコンテキストは制約や制約カテゴリ（カテゴリのすべての制約）に対してここに
バインディングできる。
制約カテゴリのバインディングはクライアントコンテキストを自動的にバインディングするため
カテゴリへの新しい制約の寄与の利点を持つ。
たとえ制約がコンテキストを意識せずにプラグインやカテゴリへのバインディングを定義できたとしても、
カテゴリバインディングは親からのサブカテゴリによって受け継がれる

5.The extension point org.eclipse.emf.validation.validationListeners is used to define validation listeners for the validation service (org.eclipse.emf.validation.service.ModelValidationService). The validation service will inform this listener whenever validation has occurred, loading it if necessary in order to do so. This is most useful for cases where client plug-ins need to find out about validation events even before they are loaded. Otherwise, it is usually simpler just to programmatically add a listener to the validation service. The value of the listener element class attribute must be the fully qualified name of a class that implements the IValidationListener interface. Listeners can also be registered in code, at run-time, using the ModelValidationService.addValidationListener() method.

拡張ポイント.org.eclipse.emf.validation.validationListenersは
validationサービスに対してvalidationリスナを定義するために利用する。
validationサービスはリスナにvalidationが起きたという情報を伝える。
もしそのようなことをするためには必要ならば、リスナをロードする。
これはクライアントプラグインがロードする前にvalidationイベントについて
理解する必要があるケースに使われる。
普通validationサービスに対してリスナをプログラム的に追加するのは簡単。
リスナ要素のクラス属性の値がLValidationListenerインタフェースを実装したクラス名を
制限されなければならない。
実行時はMdelValidationService.addValidationListerner()を使ってリスナは登録される。

6.The ModelValidationService singleton coordinates the invocation of validation. It defines a single factory method for creation of IValidator for the batch and live evaluation modes. Validators validate one or more objects at a time; the kind of object accepted as input depends on the evaluation mode. They can be configured to report constraint passes as well as failures, for verbose results. Results are reported as IValidationStatus. Validators can be reused by a client for any number of validation operations. The ILiveValidator validates EMF Notifications. The IBatchValidator validates EObjects and, due to its support for model traversal, supports progress monitors. Registered traversal strategies can be overridden by the client.

ModelValidationServiceはシングルトンでvalidationの実行を行う。
これはbatchモードliveモードに対してIValidatorを生成するファクトリメソッドを
定義する。
Validatorsは1つやそれ以上のオブジェクトをvalidateする。
評価モードに依存する入力として受けられたオブジェクトの種類。
それらは詳細な結果に対して制約の通過同様失敗のレポートすることを設定される。
結果はIValidationStatusとしてレポートされる。
Validatorはvalidation operationの数に対してクライアントは再利用する。
ILiveValidatorはEMF通知をvalidateする。
IBatchValidatorはEObjectをvalidateし、モデルトラバーサル、プログレスモニタ
をサポートする。
登録されたトラバーサルストラテジはクライアントでオーバーライドする。

7.Clients can create an EValidator implementation that delegates to the validation framework.

クライアントはvalidation frameworkを委譲したEValidator実装で作成される。

8.The framework provides implementation of an XML constraint parser (org.eclipse.emf.validation.xml.IXmlConstraintParser) API that supports definition of XML constraints in OCL. The class OclConstraintParser is the constraint parser implementation that creates instances of the OclModelConstraint class, the OCL-language constraint implementation, from XML constraint descriptors. It uses the Query class to test model elements against an OCL constraint expression.

frameworkはXML制約パーサAPIの実装を提供する。
(org.eclipse.emf.validation.xml.IXmlConstraintParser)
APIはOCLのXML制約を定義できる。
クラスOclCOntraintParserは制約パーサである。
OclModelConstraintクラスでインスタンス化された制約パース実装である。
OCL言語は制約を、実装する。
OCL制約表現に対してモデル要素のテストするためにクエリクラスを使う。

2010年1月28日木曜日

EMFQuery

先日Teneoを調べていたのだがEMFプロジェクトの中にEMF Queryというのがあり、それを使うと十分に使えるんじゃないか？思い調べてみました。
EMF Queryのサンプルからちょこっと変更を加えた下記コードのように記述すると動作することが確認されました。


public class Sample {
 public static void main(String[] args) {
  // TODO Auto-generated method stub
  BookCategory category = null;
  Collection selectedEObjects = null;
  selectedEObjects = new java.util.ArrayList();
  Library library = EXTLibraryFactory.eINSTANCE.createLibrary();
  Writer writer = EXTLibraryFactory.eINSTANCE.createWriter();
  writer.setFirstName("FirstName");
  writer.setLastName("LastName");
  writer.setName("FullName");
  for (int i = 0; i < 10; i++) {
   Book book = EXTLibraryFactory.eINSTANCE.createBook();
   book.setPublicationDate(new Date());
   book.setPages(i*100);
   book.setAuthor(writer);
   book.setCategory(BookCategory.MYSTERY_LITERAL);
   book.setTitle("タイトル"+i);
   library.getBooks().add(book);
   selectedEObjects.add((EObject) book);
   category = book.getCategory();
  }
  // PREPAREDSTATEMENT 
  SELECT select = new SELECT(
    new FROM(selectedEObjects),
    new WHERE(new EObjectAttributeValueCondition(
      EXTLibraryPackage.eINSTANCE.getBook_Pages(),
      NumberCondition.between(500, Integer.MAX_VALUE)
     )
    )
   );
  //Execute Query & getResultSet
  Collection resultset = select.execute();
  System.out.println(resultset);
  for (EObject object:resultset) {
   System.out.println(object.toString());
  }

 }
}

2010年1月26日火曜日

EMFのTeneoについて

EMFは大体理解できたが色々なさサブプロジェクトの理解ができていないため、
色々理解していこうと思います。

Teneoの和訳

TeneoはEclipseLinkやHibernateを使ったEMFに対するDB永続性のソリューションである。
DBスキーマに関連したリレーショナルマッピングへのEMFのアトミック生成をサポート。
ソリューションはEMFの特性をサポートするランタイムレイヤを含んでいる。
EMFオブジェクトは格納できる。HQLやEJB-SQLのようなクエリで検索できる。
EMFリソースの実装はEMF Editorとの統合を提供されている。
永続ロジックとマッピングはEJB3/JPAのようなアノテーションを使ってコントロールできる。
EJB3/JPAマッピングのほとんどがサポートされている。
ドキュメントとチュートリアルがelver.org で乗っている。

上記の和訳は非常に難しいことを言っているがDBのようなクエリがEMFオブジェクト
で利用できますというのが大きいです。

参考リンク
・elver

・hibernate

2010年1月24日日曜日

Pluginを作成するために便利なプラグイン

Eclipse MarketPlaceを見ていていいなぁと思ったものを紹介。

・RCP Toolbox
RichClientGUIというサイトで配布されているサンプル？ツール。
起動するとデモ+ソースコードが見れるので、それを流用してサクサク
プラグインが作成できるかもなぁということで。

・SWTXML
SWTをXMLで記述できる技術。まぁFlexに対抗するためにはやる必要な機能だもんなぁ。
これがJavaのソースコードに変換できればかっこいいのだが。調査中。

2010年1月22日金曜日

RCPのwelcome画面のカスタマイズ

RCPのWelcome画面をカスタマイズについて調べました。

・Widget編
org.eclipse.ui.introの拡張ポイントを追加
introを追加
　ID：intro
　class:HelloWorldIntroPart
introproductBindingを追加
productID:sample.product
introID:intro

HelloWorldIntroPartの実装を行います。IIntroPartインタフェースを実装する。
getTitle,getTitleImageを必ず実装します。
createPartControlを実装。
基本的にSWTで表示する方法と同じ方法で画面を作成する。

メリット：完全にSWTに紐づいているのでWelcome画面のボタンでアクションを起こすことができる。

・XHTML編
product.configurationのbrandingのwelcome PageのIntroIDを
指定する。
introIDを指定すると指定したplugin.xmlに拡張にintro,intro.config
が追加される。

content:introContent.xhtml

introContent.xhtmlとroot.xhtmlを確認し、XHTMLを編集していくことで
独自のWelcomeページを見ることができる。

・welcome画面を閉じる仕組み


private IIntroSite introsite;
private IIntroPart intropart;

workbench = PlatformUI.getWorkbench();
workbench.getIntroManager().closeIntro(intropart);

2010年1月17日日曜日

VisualEditorでのScrolledFormの編集方法

VisualEditorでScrolledFormを使って画面作成したが、再度開きなおすと編集ができなくなってしまいます。
ScrolledFormとSectionを使うのが動作的にNGっぽいのでどうしようかと考えた結果。

Compositeで作成した後ScrolledFormに手で書き換えてやれば動作するのではという結論

1.Compositeで画面を作成する。
2.大本画面のCompositeをScrolledFormに型を変換する。
3.composite.setLayout()をcomposite.getBody().setLayout()に変換
4.ウィジェット生成メソッドのcreateXXXXの引数のScrolledFormのcompositeをcomposite.getBody()に変換する。・
5.以上作成完了
6.再度編集しなおすときは上記の逆の作業を行う。

非常にめんどくさいですが、上記方法でうまくいくことを確認できたので、今のところはOKかなとおもいます。