一部のフレームワークには、500を超えるビジネス・オブジェクトを組み込むことができます。このように大規模なフレームワークでは、ユーザーと開発者の双方にとって、起動時間が非常に長くなる可能性があります。また、複数の開発者を1つのXMLフレームワーク定義ファイルを使用して作業させる場合、管理上の問題が発生する可能性もあります。
大規模なフレームワークを使用する代わりに、それを複数の小さなフレームワークに分割するという方法があります。 (アプリケーション・ベースまたはロール指向ベースなどで)分割できるとすると、例えば次のように定義された3つのフレームワークを処理することができます。
|
これら 3 つのエントリー・ポイント・フォームは、 UF_EXEC (VLF-WIN の場合) または UF_OEXEC (VLF-ONE の場合).をベースとした通常のエントリー・ポイント・フォームです。
フレームワークが3つある場合は、これらをユーザー・デスクトップの1つのフォルダーに入れ、高レベルのメニューのように使用することができます。
このメニュー・システムは、メインVLFナビゲーション・ツリーの高レベルな代替として機能します。また、エンドユーザーには編集や表示方法の豊富な選択肢を提供します。
1つのVLF-WIN フレームワークから別のフレームワークを起動するのもかなり簡単にできます。
次の VLF-ONE 非表示コマンド・ハンドラーは、別の VL フォームを汎用的に起動します。
BEGIN_COM ROLE(*EXTENDS #VF_AC020)
MTHROUTINE NAME(uExecute) OPTIONS(*REDEFINE)
Use OV_SYSTEM_SERVICE With_Args(START_LANSA ('FORM=' + #Com_Owner.avAlphaArg1))
Endroutine
End_com
例えば、Framework 1 に Framework 2、Framework 3 と Other Frameworks が含まれているとします。また、Other Frameworks アプリケーションにはFramework 2 と Framework 3 というタイトルのビジネス・オブジェクトが含まれているとします。 Framework 1のナビゲーション・ペインは次のようになります。
これは、Framework 1からFramework 2または3にアクセスする2つの方式を示しています。
Framework 1のナビゲーション・ツリーの任意のレベルで、Framework 2、またはFramework 3をクリックすると、前述の汎用的なコマンド・ハンドラーにより、別のVLプロセスとしてもう1つのフレームワークが起動されます。
Framework 2に例えば300のビジネス・オブジェクトが組み込まれている場合は、これらのビジネス・オブジェクトをFamework 1で実際に定義するというオーバーヘッドを負うことなく、Framework 1からアクセスできるようになりました。必要なのは、Framework 1に1つのアプリケーションまたはビジネス・オブジェクトを追加してリンクとして機能させるだけです。
次のように、同じコマンド・ハンドラーが各アプリケーションやビジネス・オブジェクトに定義されています。
顕著な特徴としては、コマンド・ハンドラーはデフォルトのコマンドとして定義されており、ポップアップ・メニューには表示されず、非表示コマンドとして実行され、英字パラメータ1にコマンド・ハンドラーによって起動されるVLフォームの名前が格納されているということです。
これで、フレームワークを個人のデスクトップ・アイコンまたはFramework 1のナビゲーション・ツリーから起動できるようになりました。
このサンプルには、比較的簡単に作成できる追加要素があります。以下を使用することができます。
このようなテクニックを使用すると、統合された非常に大規模なフレームワークの場合と同様の(ただし、それよりも恐らく使いやすい)結果を得ることができます。
