非常に大規模なフレームワークのオプション

非常に大規模なフレームワークのオプション

一部のフレームワークには、500を超えるビジネス・オブジェクトを組み込むことができます。このように大規模なフレームワークでは、ユーザーと開発者の双方にとって、起動時間が悩みの種になる可能性があります。また、複数の開発者を1つのXMLフレームワーク定義ファイルを使用して作業させる場合、管理上の問題が発生する可能性があります。

大規模なフレームワークを使用する代わりに、それを複数の小さなフレームワークに分割するという方法があります。(アプリケーション・ベースまたはロール指向ベースなどで)分割できるとすると、例えば次のように定義された3つのフレームワークを処理することができます。

これら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が起動したときに、ユーザーにログオン詳細を再度提供するように要求するのを回避できます。

·         異なるフレームワーク間で通信されるデータ待ち行列。各フレームワークに関連する待ち行列をリスンする「フレームワーク・マネージャー」がある場合は、フレームワーク間の通信が比較的簡単にできます。

このようなテクニックを使用すると、統合された非常に大規模なフレームワークの場合と同様の(ただし、それよりも恐らく使いやすい)結果を得ることができます。