基本的なカスタマイズ > ユーザーインタフェースのカスタマイズ > ウィザードの作成 > 単一オブジェクトを作成するウィザードの構築
単一オブジェクトを作成するウィザードの構築
目的
ユーザー入力を捕捉し、その入力からデータベース内に Windchill ビジネスオブジェクトを作成するウィザードを開発する必要があります。
バックグラウンド
Windchill には、ウィザードの作成およびウィザードステップ間の移動のためにフレームワークが提供されています。ウィザードの JSP に入力エレメントを作成するために、データユーティリティ、GUI コンポーネント、レンダリング機能、およびバリデータも用意されています。最後に、ウィザードフォーム送信時のサーバーへの送信データを処理するフレームワークがあります。これらのフレームワークとコンポーネントについては、「前提となる知識」に挙げたほかのドキュメントで説明されています。
このガイドには、特に Windchill オブジェクトの作成を目的として設計されるウィザードの開発方法と処理方法についての詳細が記載されています。定義済みのコンポーネントをビルディングブロックとして使用し、独自のウィザードを作成する方法について説明しています。以下に、主に使用されるコンポーネントを挙げます。
• 複数のウィザードに共通するウィザードステップのための操作定義
• 複数のウィザードに共通するウィザードステップの jsp および jspf ファイル
• ウィザードのデータを管理し、ページ上でエレメントを表示するためのカスタムタグ
• ユーザーがウィザードをサブミットした後にウィザードデータを処理するための Java クラス
範囲/適用可能性/前提条件
カスタムの Windchill ビジネスオブジェクトクラスまたはサブタイプを作成し、ユーザーがそのオブジェクトタイプの 1 つのインスタンスをデータベースに作成できるウィザードを開発すると仮定します。
作成するオブジェクトは永続可能でなければなりません。タイプ設定されたインタフェース、フォルダ格納済みインタフェース、および作業版数済みインタフェースについては、実装する場合としない場合があります。このガイド内で、作成するオブジェクトタイプに適さない属性について説明している箇所は無視して構いません。
このガイドでは、オブジェクトを作成する非常に基本的なウィザードの作成方法について説明します。多くの再利用可能なステップが標準で用意されています。ウィザードにこのようなステップを追加する方法については、再利用可能なウィザードステップのカスタマイズを参照してください。
必ずしも独自のカスタムウィザードを開発してカスタムタイプのインスタンスを作成する必要はありません。必要なタイプが、ウィザードのタイプピッカーですでに利用できる Windchill ビジネスクラスである場合、そのタイプ用に定義済みのウィザードを使用することもできます。定義済みのウィザードでは、WTPart、WTDocument などの指定された基本タイプのサブクラスおよびサブタイプが自動的に検出され、ユーザーがそれらのインスタンスを作成できるように、それらのサブタイプをタイプピッカーに表示します。たとえば PBPart という WTPart のソフトサブタイプを作成した場合は、以下のように新規部品ウィザードに表示されます。
タイプおよび属性の管理ユーティリティのレイアウトのサブタイプに定義した、関連付けられていない属性のいずれかを指定して、これらが非ドライバ属性テーブルの「入力」フィールドとして表示されるようにします。属性はタイプおよび属性の管理ユーティリティで指定したとおりに UI に表示されます。
このステップとは異なる順序で属性を並べるには、特にサブタイプで、このステップ用に新規の jsp を作成する必要がありますが、新規部品ウィザードを使用することもできます。
ただし、ほかのオブジェクトを新しいオブジェクトに関連付けたり、追加のウィザードステップが必要になった場合は、カスタムのウィザードを開発する必要が生じることがあります。
このガイドでは、単一のオブジェクトを作成するウィザードの開発プロセスについて説明します。オブジェクトを編集するウィザードの作成方法については、単一オブジェクトを編集するウィザードの構築を参照してください。
予測される結果
ユーザーがデータベースでビジネスオブジェクトを作成できるように、単一または複数のステップのある HTML ウィザードを製品に追加します。ウィザード内でのステップの配列と属性の表示は、一貫した操作性を実現するために、Windchill のほかのウィザードと同じようにする必要があります。
ソリューション
jsp ウィザードフレームワークをベースとして構築された共通の jsp、タグ、JavaScript、および Java クラスのコンポーネントを使用して、ユーザー入力の取得および処理とデータベース内のオブジェクトの作成に使用されるウィザードを作成します。
前提となる知識
このプロセスを適用するには、次のことを理解している必要があります。
• Java プログラミング
• JSP、カスタムタグ、および HTML フォームを使用した基本的な Web 開発
• ハードまたはソフト Windchill ビジネスオブジェクトタイプの作成方法。
独自のビジネスオブジェクトクラスの作成方法については、次の章を参照してください。
サブタイプおよび属性の作成方法については、「タイプおよび属性の管理ユーティリティの使用」を参照してください。
• 操作を使用した jsp ページおよびウィザードの起動。
操作の作成方法については、操作の追加と UI への組み込みを参照してください。
• ウィザードの作成およびウィザードデータの処理のための Windchill フレームワーク。このトピックの詳細については、ウィザードの作成を参照してください。
• テーブルやプロパティパネルを使用した UI での情報表示およびこれらのコンポーネントのデータの入手方法。詳細については、次を参照してください。
• テーブルおよびプロパティパネル内でオブジェクト属性を表示および編集するための、データユーティリティ、GUI コンポーネント、およびレンダリング機能を使用した HTML エレメントの作成。詳細については、UI の情報の表示を参照してください。
• 操作を実行するためのユーザーの機能の検証と、ウィザードに入力されたデータの検証を実行するための UI 検証サービスの使用。詳細については、操作とプロパティへの検証ロジックの追加を参照してください。
• ウィザードに適したデータ処理タスクを実行するために必要な Windchill サービス API またはその他の API
• 属性レイアウト
詳細については、属性のカスタマイズを参照してください。
このガイドには、上記に関する情報とそのコンポーネントについての追加情報が記載されており、データベースに Windchill ビジネスオブジェクトを作成するという特定の目的に適したウィザードを開発者が作成および処理できるようになっています。
このセクションで使用する用語の定義
用語
定義
基本タイプ
ウィザードのタイプピッカーのルートタイプとなるハードタイプクラスまたはサブタイプクラス。ウィザードにタイプピッカーがない場合、作成されるオブジェクトタイプは基本タイプになります。ユーザーが特定のタイプを選択するまでは、異なるサブタイプの異なる JSP バリエーションを持つウィザードステップに適切な JSP を検索するために、基本タイプが使用されます。
依存属性
値および表示特性、またはその両方が、オブジェクト初期化規則 (OIR)、アクセス制御ポリシー、またはその他のメカニズムを介して、"ドライバ属性" と呼ばれるその他の属性の値によって全体的にあるいは部分的に決定される属性。
ドライバ属性
オブジェクト初期化規則 (OIR)、アクセス制御ポリシー、またはその他のメカニズムを介して、"依存属性" と呼ばれるその他の属性の値および表示特性、またはその両方を指定する属性。
ハード属性
Java クラスで定義されるオブジェクトの属性。
ハードタイプ
Java クラスで定義されるオブジェクトのタイプ。ハードタイプは一般的に、注記を使用して java クラスに作成され、既成の Windchill ビジネスオブジェクトクラスを拡張します。
オブジェクトタイプ
作成するビジネスオブジェクトの属性と動作を定義する Java クラスまたはサブタイプ。
グローバル属性
Windchill の「タイプおよび属性の管理」クライアントで定義されるオブジェクトの属性。これらの属性は Java ビジネスオブジェクトクラスでは定義されず、Java ビジネスクラスのテーブルとは区別してデータベーステーブルに格納されます。
サブタイプ
Java クラスではなく、「タイプおよび属性の管理」ユーティリティによって定義されるオブジェクトタイプ。サブタイプによってその他のソフトタイプを拡張することができますが、すべてのサブタイプには、そのルートタイプとしてハードタイプが含まれています。
ターゲットオブジェクト
ウィザードで作成しようとしているオブジェクト。
ソリューション要素
エレメント
タイプ
説明
JSP
以下の jsp ファイルと jspf ファイルを使用すると、多くの作成ウィザードに共通するコンポーネントを作成および表示できます。特に断りがないかぎり、これらのファイルは、<WT_ホーム>/codebase/netmarkets/jsp/object および <WT_ホーム>/codebase/netmarkets/jsp/components ディレクトリにあります。
createEditUIText
JSP ファイル
作成および編集ウィザードに共通するいくつかの UI テキストが含まれています。
includeWizBean
JSP ファイル
ウィザードデータにアクセスするための JSP ページの生成中に呼び出される CreateAndEditWizBean を定義します。
Bean
CreateAndEditWizBean
Java クラス
includeWizBean jspf ファイルを含めると、この Bean をユーザーの jsp で使用できます。操作、デフォルトのコンテナ、基本タイプなど、initializeItem タグによって設定されるウィザードデータのためのゲッターメソッドがあります。
JavaScript
validateCreateLocation
フォルダブラウザツールバーから起動できるウィザードで、ウィザード操作の onClick パラメータに指定できる JavaScript メソッド。これによって、複数のチェック済みフォルダがないことと、フォルダ以外のオブジェクトがチェックされていないことが確認されます。このいずれかに当てはまると、ポップアップエラーメッセージが表示されます。
場所: <WT_ホーム>/codebase/netmarkets/javascript/util
Java クラス
ウィザードを作成および処理するために、以下のクラスを使用できます。これらのクラスは、<WT_ホーム>/codebase/WEB-INF/lib/wncWeb.jar ファイルにあります。
CreateAndEditModelGetter
Java クラス
作成ウィザードのプロパティパネルと属性テーブルのデータを生成するために getModel タグによって呼び出されるクラス。
CreateObjectFormProcessor
Java クラス
ウィザードフォームデータを処理するために使用または拡張されるクラス。DefaultObjectFormProcessor を拡張します。
DefaultObjectFormProcessorDelegate
Java クラス
さまざまな処理サブタスクを実装するために拡張されるクラス。
ObjectBean
Java クラス
単一のターゲットオブジェクト特有のフォームデータや、すべてのオブジェクトに共通するデータのコンテナ。関連するオブジェクトのフォームデータを読む込むためのメソッドを提供します。単一のオブジェクトのみを作成するウィザードには、1 つの ObjectBean しか指定できません。
FormResult
Java クラス、メソッドサーバーとクライアントで実行
サーバープロセッサメソッド間のメソッド結果のやりとりや、サーバーから WizardServlet へのメソッド結果の受け渡しに使用されるクラス。
手順 - ウィザードの作成
ウィザードを作成するには、以下の作業を行う必要があります。
• ウィザードの操作を作成する
• ウィザードのメイン jsp ファイルを作成する
• 最初のカスタムステップを作成する
• 再利用可能なステップを選択する
ウィザードの操作を作成する
新しいウィザードを起動する操作が必要になります。この操作で使用できるオプションの詳細については、ウィザード処理を参照してください。簡単な操作は次のようになります。
<objecttype name="Novel">
<action name="create">
<command class="com.ptc.core.components.forms.CreateObjectFormProcessor"
method="execute"
url="netmarkets/jsp/carambola/customization/examples/wizard/
wizardExampleTwo.jsp"
windowType="popup"/>
</action>
</objecttype>
* 
操作の標準の命名規則に従っていて、jsp ファイルのパスを <オブジェクトタイプ>\<操作名>.jsp にした場合、url パラメータは不要です。例に挙げたオブジェクトタイプは、ユーザーのシステムを混乱させないように、そうはしていません。
操作 (およびメインウィザード jsp ファイル) には "create" という名前を付けることをお勧めします。起動ポイントまたはその他の条件に基づいてオブジェクトタイプに複数の作成操作を指定する場合は、次のように、操作名にサフィックスを追加して区別することができます。
createFrom<起動ポイント>
例: createFromWorkspace
create<オブジェクトのタイプ>
例: createSharedDocument
この操作を操作モデルに追加して、システムで操作にアクセスできるようにします。
ウィザードのメイン jsp ファイルを作成する
作成するウィザードを記述した jsp を作成する必要があります。まず、wizard タグだけを記述します。ウィザードが機能するのに十分な情報は指定していませんが、これだけでも操作をクリックして、ウィザードを開くことができます。
<%@ taglib prefix="jca" uri="http://www.ptc.com/windchill/taglib/components"%>
<%@ taglib uri="http://www.ptc.com/windchill/taglib/fmt" prefix="fmt"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%>
<%@ include file="/netmarkets/jsp/components/beginWizard.jspf"%>
<%@ include file="/netmarkets/jsp/components/includeWizBean.jspf"%>
<jca:wizard title="Create Literature">
</jca:wizard>
<%@include file="/netmarkets/jsp/util/end.jspf"%>
この時点では、まだステップを定義していないため、ウィザードを起動すると、「表示する有効な操作がありません」というメッセージが表示されます。
ウィザードのメイン jsp に対して行うことのできるカスタマイズの詳細については、ウィザード処理および「サンプルコード」を参照してください。
最初のカスタムステップを作成する
カスタムウィザードステップも操作と jsp から構成されます。
操作:
<action name="createNovelStep">
<label>Welcome to your Create Novel Wizard</label>
<command url="netmarkets/jsp/carambola/customization/examples/wizard/createNovelStep.jsp"
windowType="wizard_step"/>
</action>
JSP の初期コンテンツ: Hello World.
wizard タグを更新して、ステップを含めます。
<jca:wizard title="Create Literature">
<jca:wizardStep action="createLiteratureStep" type="fakeLiterature"/>
</jca:wizard>
これで単純なウィザードを作成したことになり、ウィザードを起動すると、次のように表示されます。
これで、共通ステップの jsp ファイルで使用されるものと同一のテーブル、プロパティパネル、および JavaScript コンポーネントを使用して、固有のステップに対応した独自の jsp ファイルを開発することができます。
再利用可能なステップを選択する
定義済みのウィザードを自分のオブジェクトタイプに使用できない場合でも、定義済みのステップを再利用することはできます。
この例では、defineItemAttributesWizStep と attachments_step を追加します。これらのステップで使用できるオプションの詳細については、添付資料および再利用可能なウィザードステップのカスタマイズを参照してください。
create.jsp を更新して、これらのステップを追加します。
<%@ taglib prefix="jca" uri="http://www.ptc.com/windchill/taglib/components"%>
<%@ taglib uri="http://www.ptc.com/windchill/taglib/fmt" prefix="fmt"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"%>
<%@ include file="/netmarkets/jsp/components/beginWizard.jspf"%>
<%@ include file="/netmarkets/jsp/components/includeWizBean.jspf"%>
<jca:initializeItem operation="${createBean.create}" baseTypeName=
"wt.doc.WTDocument|org.example.FakeLiterature"/>
<jca:wizard buttonList="DefaultWizardButtons" helpSelectorKey="AssignView_help"
title="Create Literature">
<jca:wizardStep action="createLiteratureStep" type="fakeLiterature"/>
<jca:wizardStep action="defineItemAttributesWizStep" type="object"/>
<jca:wizardStep action="attachments_step" type="attachments" />
</jca:wizard>
<%@include file="/netmarkets/jsp/util/end.jspf"%>
* 
defineItemAttributesWizStep の場合、initializeItem タグも追加して、作成するタイプを設定する必要がありました。このタグと、このステップで使用できるほかのオプションの詳細については、再利用可能なウィザードステップのカスタマイズを参照してください。
これで、ウィザードは FakeLiterature オブジェクトを作成できるようになりました。この基本的な設定には多くのバリエーションがあります。詳細については、以降のカスタマイズ、以降のサンプルコード、ウィザード処理および再利用可能なウィザードステップのカスタマイズを参照してください。
カスタマイズポイント
フォームプロセッサとフォームプロセッサ委任の作成
このセクションではウィザード処理に記載されている標準的なウィザード処理フレームワークに精通していることが前提とされています。
クラス com.ptc.core.components.forms.CreateObjectFormProcessor は、永続可能オブジェクトを作成するウィザードで、デフォルトのフォームプロセッサとして使用することができます。このクラスは、必要に応じて拡張することができます。
CreateObjectFormProcessor は以下のことを行います。
preprocess() method
• 属性テーブルに記載されているように、特別な名前属性を持つ ObjectBean フォームデータのすべてを抽出します。
• 新規オブジェクトの TypeInstance を作成し、フォームの属性値を新規オブジェクトに適用して、「タイプおよび属性の管理」ユーティリティで属性に定義した制約に対して値の検証を行います。
• TypeInstance が Persistable に変換され、ObjectBean の object 属性として設定されます。
• super.preProcess() を呼び出し、ウィザードに登録される FormProcessorDelegates の preprocess() メソッドを呼び出します。
doOperation() メソッド
• super.doOperation() を呼び出し、ウィザードに登録される FormProcessorDelegates の doOperation() メソッドを呼び出します。
• PersistenceHelper.manager.store() を呼び出し、データベースに Persistable を格納します。
• getSuccessFeedbackMessage() メソッド (setResultNextAction() によって呼び出される)
▪ このメソッドは、FormResult が SUCCESS の場合に呼び出され、FeedbackMessage を作成します。メッセージの内容の設定方法については、「インラインメッセージング」を参照してください。
UI では、このインラインメッセージは単一オブジェクトの作成時に次のように表示されます。
複数オブジェクトの場合は、次のように表示されます。
CreateObjectFormProcessor は postProcess() または postTransactionProcess() メソッドを実装しないため、それらのメソッドは DefaultObjectFormProcessor から継承します。詳細については、Javadoc を参照してください。
既存の Windchill ビジネスクラスを拡張する場合、CreateObjectFormProcessor の代わりに使用または拡張する必要のある、そのクラスに特有のプロセッサが存在します。以下の表でこれらのクラスを示します。これらのクラスの動作の詳細については、Javadoc を参照してください。
クラスによる拡張対象
使用するプロセッサクラス
WTPart
ワークスペースから起動するウィザードを作成する場合 :
com.ptc.windchill.enterprise.part.forms.CreatePartFromWorkspaceFormProcessor
「構造を編集」クライアントから起動するウィザードを作成する場合:
com.ptc.windchill.enterprise.part.forms.CreatePartFromTabularInputProcessor
その他すべての単一オブジェクトの作成ウィザードの場合 :
com.ptc.windchill.enterprise.part.forms.CreatePartFormProcessor
WTDocument
テンプレートからドキュメントを作成する場合:
com.ptc.windchill.enterprise.doc.forms.CreateDocFromTe mplateFormProcessor
ドキュメントテンプレートを作成する場合:
com.ptc.windchill.enterprise.doc.forms.CreateDocTemplateFormProcessor
その他すべての単一オブジェクトの作成ウィザードの場合:
com.ptc.core.windchill.enterprise.doc.forms.CreateDocFormProcessor
WTChangeIssues
com.ptc.windchill.enterprise.change2.forms.processors.CreateProblemReportFormProcessor
WTChangeRequest2
com.ptc.windchill.enterprise.change2.forms.processors.CreateChangeRequestFormProcessor
WTChangeOrder2
com.ptc.windchill.enterprise.change2.forms.processors.CreateChangeNoticeFormProcessor
WTChangeActivity2
com.ptc.windchill.enterprise.change2.forms.processors.CreateChangeTaskFormProcessor
提供されているフォームプロセッサのいずれかの動作がニーズを満たしているのであれば、独自のプロセッサを作成する必要はありません。単に、ウィザード操作のコマンドサブタグのクラス属性値としてプロセッサを指定します。いずれの動作もニーズを満たさない場合は、ウィザードフォームデータを処理するためにプロセッサのサブクラスを作成する必要があります。単に属性を設定するために特別なコードを提供する場合は、独自のプロセッサを作成する必要はありません。その場合は、このタスクを処理するために FormProcessorDelegate を書き込むだけです。非表示フォームフィールドで FormProcessorDelegate を登録し、CreateObjectFormProcessor によって認識される特別な属性名が属性入力フィールドに指定されていないことを確認してください。
詳細については、属性テーブルを参照してください。
FormProcessorDelegate は DefaultObjectFormProcessorDelegate を継承する必要があります。NumberPropertyProcessor と KeepCheckedOutDelegate は、定義済みのカスタム FormProcessorDelegate の例です。FormProcessorDelegate のクラス構造を次に示します。
独自のプロセッサを作成する場合は、各ウィザードステップの後に、標準バリデータクラスによって preProcess() メソッドが呼び出されることに注意してください。このメソッドのデータベースを修正しないでください。
以下のより一般的な事例では、オーバーライドして処理を実行するために、独自の ObjectFormProcessor クラスとメソッドを作成する必要があります。
例 1: ウィザードの終了時に異なる操作を実行する必要がある。
たとえば、ウィザードの終了時に起動ページを再表示せずに新規のページをロードする場合です。あるいは、ウィザードを複数の位置から起動でき、起動ページを再表示する場合や、新規のページをロードする場合です。
ソリューション: 定義済みのプロセッサを部分的に分類し、setResultNextAction メソッドをオーバーライドします。NmCommand.getCompContext() メソッドから、ウィザードの起動コンテキストに関する情報を入手できます。以下にベースライン作成クライアントでこれを実行する例を示します。
String compContext = cb.getCompContext();
if (compContext != null) {
try {
NmContext compContextObj = NmContext.fromString(compContext);
Stack<NmContextItem> contextItems = compContextObj.getContextItems();
for (NmContextItem contextItem : contextItems) {
String action = contextItem.getAction();
if ("addToBaseline".equals(action) ||
"addToBaselineSingle".equals(action) ||
"addToBaselineStep".equals(action)) {

< set some next action >
}
}
.
.
.
テーブルからウィザードを起動し、ウィーザード操作で ajax="row" を指定した場合は、FormResult で refreshInfo 属性を設定し、システムに再表示する行を通知するようにします。通常、DynamicRefreshInfo オブジェクトの属性は以下のようになります。
action = NmCommandBean.DYNAMIC_ADD
oid = 作成したオブジェクトの NmOid。
location = 新規の行を含んでいるテーブルオブジェクトの NmOid。通常、これはフォルダです。
ajax 属性として "page" または "component" を使用した場合は、refreshInfo 属性を設定する必要はありません。
詳細については、Windchill JSP フレームワークを使用した HTML クライアントのカスタマイズの章のAjax による UI のカスタマイズのセクションと、FormResult および FormProcessingStatus クラスについての Javadoc を参照してください。
例 2: オブジェクトの永続化後にいくつかの後処理を実行する必要がある。
たとえば、変更管理オブジェクトウィザードには、作成後にユーザーがただちにオブジェクトをワークフローに送信できるダイアログがあります。この場合、オブジェクトの作成後に別の操作を実行する必要があります。このような条件は、入力フィールドで ObjectFormProcessorDelegate を作成し、そこでインフラストラクチャによって自動的に呼び出される postProcess() または postTransactionProcess() メソッドを実装することによって処理できる場合があります。ただし、それ以外の場合は、この処理を実行するためにフォームプロセッサを使用できます。たとえば、操作の順序が要件になっているとフォームプロセッサで操作を実行する必要があるため、FormProcessorDelegates を呼び出す順番を制御できません。
ソリューション: CreateObjectFormProcessor を部分的に分類し、postProcess() または postTransactionProcess() メソッド (DefaultObjectFormProcessor から継承) をオーバーライドして操作を実行します
(keepCheckedOutCheckbox.jspf ファイルを指定して「チェックアウト状態を維持」チェックボックスをウィザードに配置すると、KeepCheckedOutDelegate によって自動的に処理が行われます。この処理を実行する必要はありません)。
例 3: オブジェクトを永続化するのに特別な API を使用する必要がある。
たとえば、変更管理オブジェクトは、オブジェクトの永続化に加え、ライフサイクルおよびフォルダタスクを処理する StandardChangeService2 クラスで永続化します。
ソリューション: 定義済みのプロセッサを部分的に分類し、doOperation() メソッドをオーバーライドします。独自メソッドではスーパーメソッドを呼び出せませんが、登録済みの FormProcessorDelegates の doOperation() メソッドが呼び出されることを確認する必要があります。これは、DefaultObjectFormProcessor から継承される processDelegates() メソッドを呼び出すことによって実行できます。例:
FormResult doOperationResult = new FormResult();
doOperationResult.setStatus(FormProcessingStatus.SUCCESS);
doOperationResult = processDelegates (DO_OPERATION, clientData,
objectBeanList);
if (!continueProcessing(doOperationResult)) {
return doOperationResult;
}
try
{
< persist the object >
}
catch(WTException e)
{
< do error handling >
}
return doOperationResult;
委任は、多くの処理フェーズでフォームプロセッサタスクの後に呼び出されますが、doOperation フェーズでは、フォームプロセッサがタスクを実行する前に委任が呼び出される必要があります。これによって、すべての属性が設定され、オブジェクトの永続化が行われる前に、委任が操作を実行できるようになります。
例 4: プログラムで新規オブジェクトに属性を設定する必要がある。
UI で公開されない属性の永続化が実行される前に、オブジェクトで設定しなければならない属性が存在する可能性があります。
ソリューション: この処理には別の方法がいくつかあります。
• FormProcessorDelegate を作成し、その preProcess() メソッドを実装します。このメソッドで、ObjectBean のオブジェクトに属性値を設定します。委任の名前を指定するウィザード JSP に非表示フォームフィールドを追加します。このフィールドは、フレームワークによって自動的にインスタンス化が行われます。例:
<input type="hidden" name="
${createBean.formProcessorDelegateConstant}" value=" <path name
of your delegate> ">
• 定義済みのプロセッサを部分的に分類し、preProcess() メソッドをオーバーライドします。スーパークラスの createItemInstance() メソッドを呼び出して Persistable を作成し、この Persistable に目的の属性を設定することができます。例:
FormResult preProcessResult = new
FormResult(FormProcessingStatus.SUCCESS);
for (ObjectBean objBean: objectBeans) {
FormResult objectResult =
new FormResult(FormProcessingStatus.SUCCESS);
objBean.setObject(createItemInstance(clientData,
objBean, objectResult));
preProcessResult =
mergeIntermediateResult(phaseResult, objectResult);
if (!continueProcessing(preProcessResult)) {
return preProcessResult;
}
Object newObj = objBean.getObject();
< set additional attributes on the new object here>
}
// Call processDelegates() which will call registered
processor delegates
delegatesResult = processDelegates(DO_OPERATION,
clientData, objectBeanList);
preProcessResult =
mergeIntermediateResult(preProcessResult, delegatesResult);
if (!continueProcessing(preProcessResult)) {
return preProcessResult;
}
前述の例は、複数のオブジェクトを作成するウィザードでプロセッサを使用できるように作成されています。
一般に、属性を設定する場合は、今後、CreateObjectFormProcessor preprocess() メソッドへの修正が回避されるように、サブクラスアプローチではなく委任アプローチが使用されます。
制限事項
Windchill オブジェクト作成ウィザードのステップと属性を配置する場合、オブジェクトタイプ、コンテナコンテキスト、組織コンテキスト、フォルダ場所、デフォルトのライフサイクル、および新規オブジェクトのその他の属性の相互依存性に注意してください。これらの相互依存性は、以下の項目から影響を受ける可能性があります。
• タイプ定義
• オブジェクトの初期化規則 (OIR)
• アクセス制御ポリシー (ACL)
タイプ定義
多くのウィザードでは、指定した基本タイプから読み込まれるいくつかのオブジェクトサブタイプのうち、いずれか 1 つのオブジェクトサブタイプを作成できます。ソフトサブタイプまたはグローバル属性は、組織またはサイトレベルの「タイプおよび属性の管理」ユーティリティで定義できます。つまり、使用可能なオブジェクトタイプのリストが表示され、グローバル属性の入力フィールドがレンダリングされる前に、オブジェクトの組織コンテナが認識されなければなりません。また、いくつかの Windchill ビジネスタイプのデフォルトのタイプは、コンテナ、組織、およびサイトレベルで設定可能なプリファレンスによって決まるため、これらのプリファレンスも認識される必要があります。
アクセス制御ポリシー
特定のユーザーが作成アクセス許可を持っているオブジェクトのタイプは、そのオブジェクトが属する管理ドメインのアクセス制御ポリシーとアドホック規則によって定義されます。常にではありませんが、通常、管理ドメインはオブジェクトのフォルダによって決まります。さらにアクセス規則は、オブジェクトタイプのデフォルトのライフサイクルの初期状態に基づいてさらに厳密にすることが可能です。
オブジェクト初期化規則
オブジェクト初期化規則は、サイト、組織、およびコンテナレベルのオブジェクトタイプによって定義されます。このような規則では、サーバーが属性値を割り当てるのか、ユーザーが属性値を入力するのかを指定して、属性のデフォルト値を変更し、必要に応じて、属性値を編集できるかどうかや、属性のその他の表示特性を変更できます。以下に、定義済み製品で定義される OIR の属性を示します。
• 組織
• 番号
• 名前 (バリエーション部品のみ)
• フォルダの場所
• ライフサイクルテンプレート
• チームテンプレート
• バージョンスキーム
カスタマイズ担当者はこれらの OIR を修正または削除することが可能で、その他の属性の追加 OIR を作成することもできます。以下の図は、プロパティ間の OIR の実際および潜在的な相互関係を示しています。ここで、淡色表示のボックスはウィザードのエレメントを表しています。
この図を見ても分かるように、各種のオブジェクトプロパティ間の関係は複雑で分かりにくくなる可能性があります。たとえば、フォルダ場所の入力フィールドを表示するには OIR によって設定されるデフォルトのフォルダを確認する必要があり、作成されるオブジェクトタイプについて知っておく必要があります。ただし、使用可能なオブジェクトタイプを持つピッカーを表示するには管理ドメインを確認する必要があり、これはフォルダによって決められます。
このガイドでは、ほかの属性値に影響を及ぼす値の属性を "ドライバ属性" と呼んでいます。影響を受ける属性は "依存属性" と呼びます。ドライバ属性の値は、それに依存する属性値の値より "上流" で決定されなければなりません。"上流" で決定されるとは、ウィザードの起動コンテキストから決定される、あるいは、依存属性値を決めるステップより前のステップで決定されるということです。ドライバ属性と依存属性が同じステップにあったとしても、表やリストの中でドライバ属性の方が上に位置していれば、上流で決定されることになります。依存属性を持つ下流部品がプリロードされている場合、それを左右するドライバ属性が更新された際には、その下流部品も必ず更新する必要があります。(プリロードされたステップとプリロードされていないステップについては、ウィザードステップの表示の際のその内容の読み込みを参照してください。)
厳密には、属性間相互関係の本質は、サイトでの OIR の定義方法とアクセス制御ポリシーに応じて変わります。PTC が提供するウィザードは、アクセス制御規則、あらかじめ定義されている OIR、および予想される一般的なカスタマイズと矛盾しない順序で属性情報が収集されるように設定されています。顧客サイトでの OIR と ACL の設定方法については、ある条件があります。それらの条件は、以下のとおりです。
• サイトには、さまざまなオブジェクトタイプのデフォルトのライフサイクルを定義する OIR が存在する。
• OIR は、WTPart または WTDocument といった基本タイプに対してのみ定義され、これとは異なり、基本タイプのサブタイプに対しては定義されない。
これらの条件が適用されない場合や、OIR またはアクセス制御ポリシーを介して、サイトで追加属性依存が導入された場合、ウィザードステップと属性のレイアウトをカスタマイズして、常にドライバ属性が依存属性の上流になるようにする必要があります。
サンプルコード
新規ベースラインウィザードのメインの JSP
ファイル名: <WT_ホーム>/codebase/netmarkets/jsp/baseline/createBaseline.jsp
これは単一ステップのウィザードなので、<WT_ホーム>/codebase/actionmodels.xml で定義された "NoStepsWizardButtons" 操作モデルが使用されます。
<%@ taglib prefix="jca"
uri="http://www.ptc.com/windchill/taglib/components"%>
<%@ include file="/netmarkets/jsp/components/beginWizard.jspf"%>
<%@ include
file="/netmarkets/jsp/components/includeWizBean.jspf"%>
<script src='netmarkets/javascript/baseline/baseline.js'></script>
<jca:initializeItem operation="${createBean.create}"
baseTypeName="wt.vc.baseline.ManagedBaseline"/>
<jca:wizard buttonList="NoStepsWizardButtons"
helpSelectorKey="baseline.createHelp">
<jca:wizardStep action="setBaselineAttributesStep"
type="baseline" />
</jca:wizard>
%@include file="/netmarkets/jsp/util/end.jspf"%
新規製品ウィザードのメインの JSP
ファイル名: /codebase/netmarkets/jsp/baseline/create.jsp
<%@ taglib uri="http://www.ptc.com/windchill/taglib/components"
prefix="jca"%>
<%@ taglib uri="http://www.ptc.com/windchill/taglib/fmt"
prefix="fmt"%>
<%@ page import="com.ptc.windchill.enterprise.part.PartConstants"
%>
<%@ include file="/netmarkets/jsp/components/beginWizard.jspf"%>
<%@ include
file="/netmarkets/jsp/components/includeWizBean.jspf"%>
<fmt:setBundle
basename="com.ptc.windchill.enterprise.product.productResourceClie
nt"/>
<jca:initializeItem operation="${createBean.create}"
baseTypeName="wt.pdmlink.PDMLinkProduct"
<jca:wizard helpSelectorKey="PDMAdminProdCreate_Help"
buttonList="DefaultWizardButtonsNoApply">
<jca:wizardStep action="defineItemWizStep" type="object" />
<jca:wizardStep action="setAttributesWizStep" type="object" />
</jca:wizard>
<SCRIPT language="javascript">
.
.
.
</SCRIPT>
<%@ include file="/netmarkets/jsp/util/end.jspf"%>
これは役に立ちましたか?