非常に大規模なフレームワークのオプション
一部のフレームワークには、500を超えるビジネス・オブジェクトを組み込むことができます。このように大規模なフレームワークでは、ユーザーと開発者の双方にとって、起動時間が悩みの種になる可能性があります。また、複数の開発者を1つのXMLフレームワーク定義ファイルを使用して作業させる場合、管理上の問題が発生する可能性があります。
大規模なフレームワークを使用する代わりに、それを複数の小さなフレームワークに分割するという方法があります。(アプリケーション・ベースまたはロール指向ベースなどで)分割できるとすると、例えば次のように定義された3つのフレームワークを処理することができます。
|
エントリー・ポイントのフォーム名 |
フレームワークXML定義ファイル |
|
MJDFRAME1 |
Frame_1.XML |
|
MJDFRAME2 |
Frame_2.XML |
|
MJDFRAME3 |
Frame_3.XML |
これら3つのエントリー・ポイントのフォームは通常のVLFエントリー・ポイントのフォームです。
Function Options(*DIRECT)
BEGIN_COM ROLE(*EXTENDS #VF_AC006)
Mthroutine Name(uInitializeFramework) Options(*Redefine)
Set Com(#Com_Owner) IDesignMode(FALSE) Uadminmode(FALSE)
Set Com(#Com_Owner) Usystemxmlfile(‘<<Framework’s XML file definition file>>')
Endroutine
End_com
フレームワークが3つある場合は、これらをユーザー・デスクトップの1つのフォルダーに入れ、高レベルのメニューのように使用することができます。
このメニュー・システムは、メインVLFナビゲーション・ツリーの高レベルな代替として機能します。また、エンド・ユーザーには編集や表示方法の豊富な選択肢を提供します。
さらに、通常は、VLFナビゲーション・ツリー内を移動するよりも、異なるウィンドウで開かれている複数のアプリケーション領域を切り替える方が簡単にできます。
1つのフレームワークから別のフレームワークを起動するのもかなり簡単にできます。次のVLF非表示コマンド・ハンドラーは、別の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のナビゲーション・ツリーから起動できるようになりました。
このサンプルには、比較的簡単に作成できる追加要素があります。以下を使用することができます。
· もう1つのフレームワークがすでにアクティブであるどうかを確認し、インスタンスがもう1つ起動するのを防ぐマーカー・ファイルまたはデータ待ち行列。
· ログオン詳細をフレームワーク間でやり取りする独自のログオンIIPおよび暗号化された一時ストリーム・ファイル。このようにして、Framework 1はログオン/接続詳細の最後のセットを取得できます。Framework 2または3が起動したときに、ユーザーにログオン詳細を再度提供するように要求するのを回避できます。
· 異なるフレームワーク間で通信されるデータ待ち行列。各フレームワークに関連する待ち行列をリスンする「フレームワーク・マネージャー」がある場合は、フレームワーク間の通信が比較的簡単にできます。
このようなテクニックを使用すると、統合された非常に大規模なフレームワークの場合と同様の(ただし、それよりも恐らく使いやすい)結果を得ることができます。