事前検証のバリデータの実装
ソリューションベース、役割ベース、フィルタのチェックにパスしたとします。事前検証アクティビティを実行するとき、最後に検証サービスが行うのは、UI コンポーネントに関連付けられたバリデータを呼び出すことです。前述したとおり、通常のバリデータには単一の UI コンポーネントまたは少数の関連コンポーネントセットに固有の事前検証ロジックが含まれます。つまり、検証ロジックがコンポーネント間で同一であれば、単一のバリデータを複数の UI コンポーネントに関連付けることができます。ただし、その場合はフィルタの使用も適しています。フィルタを使用する利点は、あるコンポーネントのロジックがその他のコンポーネントと異なるようになった場合はいつでも、バリデータを後で追加するオプションを確保できることです。
制限付き事前検証と完全事前検証
バリデータに定義する事前検証メソッドには、実際は "制限付き" 事前検証と "完全" 事前検証の 2 つがあります。実装する各メソッドは、performLimitedPreValidation() および performFullPreValidation() と呼ばれます。
制限付き事前検証と完全事前検証を区別するのは、パフォーマンスの考慮が目的です。パフォーマンスを考慮する必要がある場合、クライアントインフラストラクチャは検証サービスに制限付き事前検証の実行を求めます。現在のところ、操作に対する制限付き事前検証が要求されるのは、行レベルの "操作アイコン" がテーブルまたはツリーで事前検証される場合に限られます。属性については、制限付き事前検証が常に要求されます。
バリデータ開発者が、いつ制限付き事前検証を呼び出すか、いつ完全事前検証を呼び出すかを計算する必要はありません。両方のメソッド (performLimitedPreValidation() と performFullPreValidation()) をバリデータに実装しておけば、インフラストラクチャが特定の状態に合わせて適切なメソッドを呼び出します。performLimitedPreValidation() と performFullPreValidation() メソッドがまったく同じロジックを持つことは問題なく、多くの場合そうなっています。
既出の制限付き事前検証
50 行のテーブルがあり、各行に 5 つの行レベルの操作アイコンがあるとします。テーブルがレンダリングされる前に、250 (50 行 × 5 操作) の事前検証チェックが実行され、各行でどの操作を使用可能にするかを決めます。各検証チェックに .01 秒かかるとすると、ページがレンダリングされる前の事前検証だけでも 2.5 秒かかってしまいます。
この場合は、検証の "正確性" よりも "パフォーマンス" を優先することが考えられます。このような場合、クライアントインフラストラクチャは検証サービスに "制限付き" 事前検証の実行を求めます。バリデータは制限付き検証を呼び出したときには "負担の大きい" 検証チェックは行わず、不明な場合は操作を有効にします。
つまり、操作をユーザーに許可するかどうかを判断するためにアクセス許可を確認する必要があるとします。しかし、アクセス許可のチェックには大きな負担がかかります。そこで、バリデータの performLimitedPreValidation() で、アクセス許可のチェックをスキップし、ユーザーが適切なアクセス許可を持つと見なします。最悪でも、ユーザーに操作が表示され、有効であるものの、そのユーザーが操作を起動しようとすると、選択後検証がより詳細なチェックを実行し、ユーザーによる操作の実行を拒否します。これが、制限付き事前検証で "正確性" よりも "パフォーマンス" を優先するという意味です。
既出の完全事前検証
一方、テーブル行または情報ページの "ドロップダウン" 操作リストの操作を事前検証するとします。ユーザーがドロップダウンリストを選択した後、(ページが最初にレンダリングされるときと異なり) Ajax を使用して入力しているので、パフォーマンスはあまり問題になりません。いくつかの操作については検証を行いますが、それも単一コンテキストオブジェクトに限られます。
このような場合は、パフォーマンスよりも検証の正確性を優先する方が適切です。制限付き事前検証で説明した同じ例について考えみると、ある操作をユーザーに許可するかどうかを判断するために、アクセス許可のチェックを実行する場合は、バリデータの performFullPreValidation() メソッドでそのチェックを行う負担は許容範囲内となります。チェックには余計に時間がかかるかもしれませんが、ページ (または Ajax コンポーネント) がレンダリングされる前に実行する検証数は処理可能なレベルなので、パフォーマンスの低いチェックも許容できます。
多くの場合、バリデータの performFullPreValidation() と performLimitedPreValidation() メソッドの実装はまったく同一であることに留意してください。
バリデータの作成
バリデータクラスを作成する方法は非常に単純です。com.ptc.core.ui.validation.DefaultUIComponentValidator を拡張するクラスを作成するだけです。
以下のクラスは、単純バリデータクラスのスケルトンを表します。
package com.ptc.windchill.enterprise.myPackage.validators;
import com.ptc.core.ui.validation.DefaultUIComponentValidator;
public class MyValidator extends DefaultUIComponentValidator{
//override one or more validation methods from
DefaultUIComponentValidator
}
事前検証メソッドの実装
バリデータクラスのスケルトンを作成した後で、属性の事前検証ロジックを追加する場合は、performLimitedPreValidation () メソッドを実装します。操作の事前検証ロジックを追加する場合は、performFullPreValidation() と performLimitedPreValidation() 両方のメソッドの実装が必要になります。制限付き事前検証と完全事前検証の実装については、前のセクションで説明したとおり、まったく同じ場合も異なる場合もあります。次のページのクラスに、これらの方法のいくつかのスケルトン実装を示します。
public class MyValidator extends DefaultUIComponentValidator{
@Override
public UIValidationResultSet performFullPreValidation()
(UIValidationKey validationKey,
UIValidationCriteria validationCriteria, Locale
locale) throws WTException {
UIValidationResultSet resultSet =
UIValidationResult.newInstance();
// perform your business logic here
// if you want to enable the action/component, do this:
//
resultSet.addResult(UIValidationResult.newInstance(validationKey,
// UIValidationStatus.ENABLED));
// if you want to disable the action/component, do this:
//
resultSet.addResult(UIValidationResult.newInstance(validationKey,
// UIValidationStatus.DISABLED));
// if you want to hide the action/component, do this:
//
resultSet.addResult(UIValidationResult.newInstance(validationKey,
UIValidationStatus.HIDDEN));
return resultSet;
}
@Override
public UIValidationResultSet performLimitedPreValidation()
(UIValidationKey validationKey,
UIValidationCriteria validationCriteria, Locale
locale) throws WTException {
UIValidationResultSet resultSet =
UIValidationResultSet.newInstance();
// perform your business logic here
// if you want to enable the action/component, do this:
//
resultSet.addResult(UIValidationResult.newInstance(validationKey,
// UIValidationStatus.ENABLED));
// if you want to disable the action/component, do this:
//
resultSet.addResult(UIValidationResult.newInstance(validationKey,
// UIValidationStatus.DISABLED));
// if you want to hide the action/component, do this:
//
resultSet.addResult(UIValidationResult.newInstance(validationKey,
UIValidationStatus.HIDDEN));
return resultSet;
}
}
バリデータの登録
バリデータを作成し、適切な事前検証メソッドを実装した後は、登録するだけです。検証対象の操作または属性に関連付けるために、バリデータを登録する必要があります。
操作のバリデータを登録する場合は、操作名のみを使用して、または操作名とオブジェクトタイプの組み合わせを使用して関連付けを作成します。ほとんどの場合、操作名のみでバリデータの識別を十分に行うことができるので、この方法を推奨します。属性のバリデータを登録する場合は、属性の descriptor ID を使用して関連付けを作成します。
基本的なバリデータ登録
バリデータを登録するには (操作の操作名のみを使用)、以下のようにエントリを *service.properties.xconf に追加する必要があります。
<Service context="default"
name="com.ptc.core.ui.validation.UIComponentValidator">
<Option requestor="null" serviceClass="[完全修飾バリデータクラス]"
selector="[操作名/属性 descriptor ID]" />
</Service>
*service.properties に適用されると、以下のようなエントリができます。
wt.services/svc/default/com.ptc.core.ui.vali
dation.UIComponentValidator/[操作名/属性 descriptor ID]/null/0=[完全修飾バリデータクラス]/duplicate
• この場合、requestor 属性は null となります。つまり操作のオブジェクトタイプは照会で使用されません。
タイプベースのバリデータ登録
操作名に加えて、操作のオブジェクトタイプも使用して登録した方が適していると考えられる場合に使用します。操作名のみの登録と非常によく似ています。違いは、プロパティエントリ内の requestor 属性です。オブジェクトタイプを使用しないバリデータの場合、requestor 属性は null に設定されます。これに対して、オブジェクトタイプを使用して登録するバリデータの requestor 値は、登録対象タイプの完全修飾クラス名となります。
requestor 属性で使用されるクラス名は、actions.xml のクラス名に対応します。
たとえば、以下に一部を示すように、actions.xml ファイルを作成します (注記: 読みやすいように、一部のテキストを省略しています)。
この場合、操作名は create です。当然、システムでは create という名称でいくつもの操作が定義されているでしょう。しかし、各 create 操作の検証規則は、作成するオブジェクトタイプによって異なる場合があります。このため、たとえば問題レポート、部品の create 操作などの create 操作に対しては、個別のバリデータを設定する方が適しています。
com.ptc.windchill.enterprise.change2.validators.ChangeMgmtCreateWizardsValidator という名称で定義したバリデータがあり、create 操作に登録するとします。ただし、問題レポートの create 操作にのみ適用されます。
前述の actions.xml エントリを調べ、問題レポートの create 操作が problemReport という名称の objecttype に定義されているかを確認し、さらに重要な事項として、クラスが wt.change2.WTChangeIssue であることを確認します。
actions.xml の class 値をプロパティエントリの requestor 属性として使用することで、検証サービスに対して、オブジェクトタイプが wt.change2.WTChangeIssue である create 操作のバリデータ (com.ptc.windchill.enterprise.change2.validators.ChangeMgmtCreateWizardsValidator) のみの登録を指示することができます。次のようになります。
<Service context="default"
name="com.ptc.core.ui.validation.UIComponentValidator">
<Option
serviceClass="com.ptc.windchill.enterprise.change2.validators.Chan
geMgmtCreateWizardsValidator"
selector="create" requestor="wt.change2.WTChangeIssue" />
</Service>
これですべての指示が含まれます。基本的に、操作のバリデータを登録するときに、操作が特定のオブジェクトタイプ (actions.xml 内で) に関連付けられているものに限定する場合は、actions.xml の class 属性をプロパティエントリの requestor 属性として使用します。
その他の注記:
• このタイプベースの照会は、現在のところ actions.xml で定義された操作にのみ使用できます。属性やその他の UI コンポーネントには使用できません。
• これを可能にするには、actions.xml エントリの class 属性を具象クラスにする必要があります (インタフェースではありません。多くのケースで、class 属性は現在 wt.fc.Persistable に設定されています)。既存の class 属性はほとんどの場合、インフェースから具象クラスに変更しても問題ありません。ただし、実行する前に修正する actions.xml ファイルのオーナーに確認をしてください。
バリデータ登録の検証
特定の操作または属性に対してどのバリデータが登録されているかを確認するために、実行可能なコマンドラインレポートがあります。作成したバリデータがこのレポートに表示されない場合は、正しく登録されていないため、呼び出すことができません。
以下に例を示します。
単一バリデータの検索 (非タイプベース)
• 使用例 1 - pasteAsCopy 操作に登録したバリデータの検索:
Y:\>java com.ptc.core.ui.validation.UIComponentValidatorFactory
pasteAsCopy
登録済みバリデータ:
pasteAsCopy ->
com.ptc.core.foundation.saveas.validators.PasteValidator
複数のバリデータの検索 (非タイプベース)
• 使用例 2 - setState と pasteAsCopy 操作に登録したバリデータの検索:
Y:\>java com.ptc.core.ui.validation.UIComponentValidatorFactory
setState pasteAsCopy
登録済みバリデータ:
setState ->
com.ptc.windchill.enterprise.lifecycle.validators.SetStateValid
ator
pasteAsCopy ->
com.ptc.core.foundation.saveas.validators.PasteValidator
単一バリデータの検索 (タイプベース)
• 使用例 3 - create 操作に登録したバリデータの検索、actions.xml の objecttype name 属性が problemReport: (注記: タイプベースの照会を行うには、メソッドサーバーが動作中でなければなりません)
Y:\>java com.ptc.core.ui.validation.UIComponentValidatorFactory
create:problemReport
登録済みバリデータ:
create:problemReport(wt.change2.WTChangeIssue) ->
com.ptc.windchill.enterprise.change2.validators.ChangeMgmtCreat
eWizardsValidator
複数のバリデータの検索 (タイプベースと非タイプベースの組み合わせ)
• 使用例 4 - pasteAsCopy 操作と create 操作に登録したバリデータの検索、create 操作は、actions.xml の objecttype name 属性が problemReport: (注記: タイプベースの照会を行うには、メソッドサーバーが動作中でなければなりません)
Y:\>java com.ptc.core.ui.validation.UIComponentValidatorFactory
pasteAsCopy create:problemReport
登録済みバリデータ:
pasteAsCopy ->
com.ptc.core.foundation.saveas.validators.PasteValidator
create:problemReport(wt.change2.WTChangeIssue) ->
com.ptc.windchill.enterprise.change2.validators.ChangeMgmtCreat
eWizardsValidator