第13章
この章では、exteNd Directorイベントモデルおよびイベント処理の概念について説明します。この章は、次の節から構成されています。
exteNd Director イベントモデルはJavaのイベントリスナ/プロデューサを拡張したものです。 「イベント」は軽量通知オブジェクトで、 1つまたは複数の「イベントリスナ」に関連する情報を含んでいます。 リスナは適切な方法でイベントに応答します。 exteNd Director で主にイベントを使用するのはコンテンツ管理(CM)サブシステムで、さまざまなCM操作のイベントオブジェクトを定義します。 たとえば、ドキュメントの作者、題名、およびその他のデータに関する情報を保有するイベントを生成する、「ドキュメント追加」操作のリスナを登録することができます。 ログを作成したり、印刷ストリームへ出力したり、または電子メールで送信したりと、イベントはさまざまな形で利用きます。exteNd Directorでは、CM、WebDav、およびCMタスク管理操作用の所定イベント一式を用意し、拡張可能なイベントフレームワークを提供しています。
この章では、exteNd Directorの基本概念について説明します。 特定のサブシステム用のイベントサポートについての詳細は、次を参照してください。
|
サブシステム、または関数 |
イベントについての情報 |
|---|---|
|
CMサブシステム |
|
|
CMタスク |
|
|
WebDAV |
exteNd Director イベントモデルは次のオブジェクトタイプで構成されています。
「イベント処理」とは、イベントリスナの「イベントハンドラメソッド」がイベントプロデューサによって呼び出された後に、リスナが特定のイベントを処理することです。 このため、イベントリスナは「イベントハンドラオブジェクト」として機能します。 イベント処理の過程を表す流れ図は次のとおりです。 この流れでは、CMリポジトリ更新のような、データベースに関連するイベントを想定しています。
ここでは、いくつかの一般リスナがイベントプロデューサに登録されている、という筋書きです。 ユーザがCMリポジトリへドキュメントを追加するというような、プロデューサのイベントドメイン内にあるアクションが発生しました。 イベント処理の順序は次のとおりです。
アクションが実行された場合、イベントプロデューサはイベントオブジェクトのインスタンスを生成し、それに適切な情報を与えます。
イベントプロデューサは、各リスナのためにstateChanged()イベントハンドラを呼び出し、イベントオブジェクトへ引き渡します。
注記: イベントプロデューサは、リスナが登録された順に登録を通知します。
ここでは、いくつかの拒否可能および一般リスナがイベントに登録され、アクションが拒否されたという筋書きです。 イベント処理の順序は次のとおりです。
最後は、いくつかの拒否可能および一般リスナがイベントに登録され、アクションが拒否され なかったという筋書きです。 イベント処理の順序は次のとおりです。
この節は、 exteNd DirectorイベントAPIについての概要です。
この図は、イベントオブジェクトのクラス階層を示します。
また、図にはありませんが、イベントAPIはイベント監視に関連するクラス定数も含んでいます。
この図はイベントプロデューサインタフェースのクラス階層を示します。
この図はイベントリスナインターフェースのクラス階層を示します。
イベントをアプリケーションで実装するには、まずはじめに、どんなイベントを使用するか、およびどのようにイベントを処理するかを決める必要があります。
監視する動作のタイプを説明します。 コンテンツ管理要素の場合、リポジトリのどんな要素(ディレクトリ、ドキュメント、またはドキュメントタイプなど)を使用するかを決定します。
イベントをどう処理する必要があるかを考えます。 一般的には、当事者に通知したり、イベントをログに記録したり、またはその他の方法で応答します。
イベントスキームの実装には、次のステップが必要です。
イベント処理は通常、ログへの記録や当事者への電子メール送信など、何らかの通知が必要になります。exteNd Directorでは、次のイベント通知をサポートしています。
|
通知リスナ |
機能 |
|---|---|
|
指定の宛先へ電子メールを送信します |
|
|
指定したログの記録します |
|
|
指定した印刷ストリームへ書き込みをします |
通知リスナが適切なファクトリメソッドを使用するように設定することができます。たとえば、次のとおりです。
EbiMailStateChangeListener listener = com.sssw.fw.event.factory.EboFactort.getMailStateChangeListener();
次の例は、デフォルトリスナに委任することにより、EbiMailStateChangeListenerを実装するクラスを作する方法を説明しています。
public class MyClass implements com.sssw.fw.event.api.EbiStateChangeListener {
protected EbiMailStateChangeListener m_scl;
public void stateChanged(EboStateChangeEvent event) {
try
{
EbiMailStateChangeListener scl = getScl();
scl.setMsgText(…);
// provide other settings ...
scl.stateChanged(event);
}
catch (Exception ex) {
// handle exceptions here
}
}
protected EbiMailStateChangeListener getScl() throws EboFactoryException {
if (m_scl == null)
m_scl = com.sssw.fw.event.factory.EboFactory.getMailStateChangeListener();
return m_scl;
}
}
操作を拒否するには、拒否可能リスナのvetoableStateChanged()イベントで拒否条件を定義し、falseを返します。イベントプロデューサは、操作を拒否し、com.sssw.fw.exception.EboOperationVetoedExceptionをスローすることにより応答します。
EboOperationVetoedExceptionはランタイム例外なので、操作メソッドのthrows節には含まれていません。 ただし、例外はコードのどこかで処理する必要があります。 たとえば、 コンテンツ管理の「ドキュメントの追加」イベントを含めた拒否リスナを追加した場合、次に示すように、addDocument()メソッドの例外を処理します。
try
{
EbiContentMgmtDelegate cmgr = ...
EbiAddDocumentParams params = ...
EbiDocument doc = cmgr.addDocument(context, params);
.....
}
catch (EboUnrecoverableSystemException ue)
{
// handle unrecoverable system exception
}
catch (EboSecurityException se)
{
// handle security exception
}
catch (EboItemExistenceException iee)
{
// handle item existence exception
}
catch (EboOperationVetoedException ove)
{
// handle operation vetoed exception
}
catch (Exception e)
{
// handle any other exception
}
リスナを作成するには、アプリケーションコードにリスナのインタフフェースを1つまたは複数実装する必要があります。一般(拒否可能ではない)リスナを作成するには、次に示すように、stateChanged()メソッド用の実装を提供します。
public class MyClass implements
com.sssw.fw.event.api.EbiStateChangeListener {
public void stateChanged(EboStateChangeEvent event) {
// perform action, inspect event, and notify...
}
}
重要: スーパークラスであるEbiEventListener ( EbiStateChangeListenerによって拡張されています)のメソッド4つに実装を提供する必要があります。 これは拒否可能リスナを作成する場合にも該当します。
拒否可能リスナの作成 拒否可能リスナを作成するには、次に示すように、vetoableStateChanged() メソッド用の実装を提供します。
public MyClass implements EbiVetoableStateChangeListener
{
public boolean vetoableStateChanged(EboStateChangeEvent event)
{
// Inspect event:
// If vetoed, return false
// If not vetoed return true and perform action
}
}
重要: アクションや操作が拒否されると、イベントプロデューサはEboOperationVetoedExceptionというランタイム例外をスローします。拒否可能リスナの使用を参照してください。
イベントを登録するには、EbiStateChangeProducer、またはそのサブクラスにあるリスナ追加メソッドを使用します。
イベントリスナを追加すると、addStateChangeListener()またはaddVetoableStateChangeListener()を使用して、Java BitSetに登録するためのさまざまなイベントを指定することができます。たとえば、次のとおりです。
EbiStateChangeProducer producer = new EbiStateChangeProducer() BitSet events = new BitSet(); events.set(MyEvent.getEventID());//interested in MyEvent events.set(MyEvent2.getEventID());//interested in MyEvent2 producer.addStateChangeListener(events, MyListenerClass);
コンテンツ管理、WebDAV、およびタスク管理のイベントIDは、それぞれのサブシステムAPIパッケージで定数として定義されています。 また、com.sssw.cm.apiはBitSetを追加するためのヘルパーメソッドをいくつか提供しています。
詳細については、『コンテンツ管理ガイド』のイベントヘルパークラスの使用に関する節を参照してください。
自分独自の状態変更イベントおよびイベントプロデューサを記述して、イベントAPIを拡張することができます。
カスタム版のaddStateChangeListener()メソッドを使用する、自分だけのイベントプロデューサを記述をできます。状態変更プロデューサを作成するには、com.sssw.fw.event.api.EbiStateChangeProducer インタフェースを実装します。
次の例は、デフォルトのイベントプロデューサに委任する方法を示しています。 ファクトリメソッドが使用され、デフォルトの状態変更プロデューサを取得し、説明とログを追加し、およびaddStateChangeListener()への実装を提供しています。
public class MySCP implements
com.sssw.fw.event.api.EbiStateChangeProducer {
protected EbiStateChangeProducer m_scp;
public MySCP() {}
public boolean addStateChangeListener(BitSet events, EbiStateChangeListener listener) {
getScp().addStateChangeListener(events, listener);
}
// \x85 .
// other EbiStateChangeProducer methods, implemented with addStateChangeListener()…
// \x85 .
protected EbiStateChangeProducer getScp() {
if (m_scp == null) {
m_scp = com.sssw.fw.event.factory.EboFactory.getStateChangeProducer();
m_scp.setScpDescription("My state change event producer");
m_scp.setScpLog(EboLogFactory.getLog(MYLOG));
}
return m_scp;
}
}
カスタムの状態変更イベントはcom.sssw.fw.event.api.EboStateChangeEventを拡張する必要があります。スーパークラスでabstractと記されている次の2つのメソッドを実装します。
public abstract int getEventID();
public abstract String getVerboseDescr();
注記: exteNd DirectorフレームワークAPIは、1から8000までの値を保有しているため、自分のイベントIDにはこの範囲外の値を使用します。
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...