EGL プロジェクト、パッケージ、およびファイル

EGL プロジェクトには、ソース・フォルダーがゼロから多数まで含まれています。それぞれのフォルダーには、 パッケージがゼロから多数まで含まれています。それぞれのパッケージには、ファイルがゼロから多数まで含まれています。 それぞれのファイルには、パーツがゼロから多数まで含まれています。

EGL プロジェクト

EGL プロジェクトは、後述する一連のプロパティーによって特徴付けられています。EGL プロジェクトのコンテキストでは、 特定のタスク実行時 (例えば、EGL ソース・ファイルまたは EGL ビルド・ファイルの保管時) に、 EGL は自動的に検証を実行し、パーツ参照を解決します。 また、PageHandler パーツまたは VGUIRecords の操作を行う場合、EGL は、以下の場合にかぎり自動的に 出力を生成します。
  • 次のオプション「ウィンドウ」>「設定」>「ワークベンチ」>「リソース変更時にビルドを自動的に実行」の選択後に、 自動ビルド・プロセスを設定した場合
  • デフォルトのビルド記述子が設定またはプロパティーとして設定されている場合

EGL プロジェクトを構成するには、新規プロジェクトの作成時にプロジェクト・タイプとして EGL または EGL Web を選択します。 プロジェクト作成ステップを実行中に、プロパティーを割り当てます。 これらのステップの完了後に選択を変更するには、 プロジェクト名を右マウス・ボタン・クリックし、表示されたコンテキスト・メニューで、 「プロパティー」をクリックします。

EGL プロパティーには、次のものがあります。
EGL ソース・フォルダー
プロジェクトのパッケージのルートである 1 つ以上のプロジェクト・フォルダー。各フォルダーは、サブディレクトリーの集合です。 ソース・フォルダーは、Java™ ファイルとは区別して EGL ソースを保持したり、Web デプロイメント・ディレクトリー以外の場所に EGL ソース・ファイルを保持する場合に役立ちます。 どのような場合でも、EGL ソース・フォルダーを指定することをお勧めします。 ただし、ソース・フォルダーが指定されていない場合には、唯一のソース・フォルダーはプロジェクト・ディレクトリーになります。

このプロパティーの値は、プロジェクト・ディレクトリーの .eglpath という名前のファイルに格納され、 EGL ソース・ファイルの保管に使用するリポジトリー (存在する場合) に保管されます。

それぞれの EGL プロジェクト・ウィザードは、EGLSource という名前の 1 つのソース・フォルダーを作成します。

EGL ビルド・パス
現行プロジェクトに存在しない任意のパーツで検索されるプロジェクト・リスト。

このプロパティーの値は、プロジェクト・ディレクトリーの .eglpath という名前のファイルに格納され、 EGL ソース・ファイルの保管に使用するリポジトリー (存在する場合) に保管されます。

次の .eglpath ファイルの例では、EGLSource は現行プロジェクト内のソース・フォルダーで、AnotherProject は EGL パス内のプロジェクトです。
  <?xml version="1.0" encoding="UTF-8"?>
  <eglpath>
    <eglpathentry kind="src" path="EGLSource"/>
    <eglpathentry kind="src" path="¥AnotherProject"/>
  </eglpath>

AnotherProject のソース・フォルダーは、その プロジェクトの .eglpath ファイルによって判別されます。

デフォルトのビルド記述子
出力を迅速に生成できるビルド記述子 (『ワークベンチでの生成』を参照)

パッケージ

パッケージは、関連するソース・パーツの名前付きコレクションです。名前には、大/小文字の区別があります。 例えば、myPkgMYPKG とは異なります。

ビルド・パーツを作成するときに、パッケージは使用されません。

規則に従って、パッケージ名の最初の部分を組織のインターネット・ドメイン名を語順反転したものにすることによって、 パッケージ名の一意性を実現します。 例えば、IBM® ドメイン名は、ibm.com® であり、EGL パッケージは「com.ibm」で始まります。 この規則を使用することによって、組織が開発した Web プログラム名は、 他の組織が開発したプログラム名と重複しないということが保証され、 名前が衝突することなく同一サーバーにインストールできます。

個々のパッケージのフォルダーは、パッケージ名によって識別されます。これは、ID をピリオド (.) で区切ったシーケンスです。例を次に示します。
  com.mycom.mypack
それぞれの ID は、EGL ソース・フォルダー内のサブフォルダーに対応しています。 例えば、com.mycom.mypack のディレクトリー構造は ¥com¥mycom¥mypack で、 ソース・ファイルは最下位のフォルダー (この場合には mypack) に格納されます。 ワークスペースが c:¥myWorkspace、プロジェクトが new.project、ソース・フォルダーが EGLSource の場合には、このパッケージのパスは次のようになります。
  c:¥myWorkspace¥new.project¥EGLSource¥com¥mycom¥mypack

EGL ソース・ファイル内のすべてのパーツは同一のパッケージに属します。 ファイルの package 文がある場合、その文でそのパッケージ名を指定します。 package 文を指定しない場合には、パーツはソース・フォルダーに直接格納されます。 つまり、デフォルト・パッケージに格納された状態になります。 package 文は、常に指定することをお勧めします。 これは、デフォルト・パッケージ内のファイルは、他のパッケージまたはプロジェクト内のパーツによって共有できないためです。

同一の ID を持つ 2 つのパーツは、同じパッケージに定義することはできません。 同じパッケージ名を異なるプロジェクトまたは異なるフォルダーで使用しないことを特にお勧めします。

生成された Java 出力のパッケージは、EGL ソース・ファイル・パッケージと同じです。

EGL ファイル

すべての EGL ファイルは、以下のいずれかのカテゴリーに含まれます。

ソース・ファイル
EGL ソース・ファイル (拡張子 .egl) には、ロジック、データ、およびユーザー・インターフェース・パーツが含まれ、EGL ソース形式で作成されています。
以下の生成可能パーツは、コンパイル可能単位に変換できます。
  • DataTable
  • FormGroup
  • Handler (レポート・ハンドラーの基礎)
  • Library
  • PageHandler
  • Program
  • VGUIRecord

EGL ソース・ファイルには、生成不可能なパーツをゼロ個以上いくつでも組み込むことができますが、 生成可能パーツは 1 つだけ組み込むことができます。 生成可能パーツ (存在する場合) は、ファイルの最上位にある必要があり、そのファイルと同じ名前になっている必要があります。

ビルド・ファイル
EGL ビルド・ファイル (拡張子 .eglbld) には、ビルド・パーツをいくつでも組み込むことができ、Extensible Markup Language (XML)、EGL ビルド・ファイル形式で作成されています。 関連する DTD (以下のディレクトリーにあります) を検討することができます。
installationDir¥egl¥eclipse¥plugins¥
com.ibm.etools.egl_version
installationDir
製品のインストール・ディレクトリー。例えば、C:¥Program Files¥IBM¥Rational¥SPD¥6.0 など。 これから使用しようとしている製品をインストールする前に Rational® Developer 製品をインストールし、保持していた場合は、以前のインストール時に使用されていたディレクトリーを指定することが必要になる場合があります。
version
インストール済みのプラグインのバージョン (例: 6.0.1)

ファイル名 (egl_wssd_6_0.dtd など) は、文字 egl およびアンダースコアーで開始します。wssd の文字は Rational Web デベロッパーおよび Rational Application Developer を指します。wsed の文字は、Rational Application Developer for z/OS® を指し、wdsc の文字は Rational Application Developer for iSeries™ を指します。

パーツをファイルに追加した後に、リポジトリーを使用して 変更のヒストリーを管理することができます。

推奨

このセクションでは、ユーザーの開発プロジェクトの設定に関する推奨事項について説明します。

ビルド記述子の場合

チーム・プロジェクトでは、ビルド記述子開発者として 1 人を指名する必要があります。 開発者の作業は以下のとおりです。
  • ソース・コード開発者用のビルド記述子を作成する
  • これらのビルド記述子をソース・コード・プロジェクトとは別のプロジェクトに配置する。 さらに、リポジトリーまたはその他の方法で、その別のプロジェクトを利用可能にします。
  • ソース・コード開発者に、プロジェクト内にプロパティー・デフォルトのビルド記述子を設定するように依頼する。これによって、このプロパティーは、 適切なビルド記述子を参照します。
  • ビルド記述子オプションの小さなサブセット (ユーザー ID およびパスワードなど) が、1 人のソース・コード開発者と次のソース・コード開発者で異なる場合には、それぞれのソース・コード開発者に以下を行うよう依頼します。
    • nextBuildDescriptor オプションを使用してグループ・ビルド記述子を指す個人用ビルド記述子をコード化する。
    • ソース・コード開発者に、ファイル、フォルダー、またはパッケージ内にプロパティー・デフォルトのビルド記述子を設定するように依頼する。 これにより、このプロパティーは、個人用ビルド記述子を参照します。 開発者は、プロパティーをプロジェクト・レベルでは設定しません。 これは、プロジェクト・レベルのプロパティーが、他のプロジェクト情報とともに、リポジトリーによって制御されるためです。

追加情報については、『ビルド記述子パーツ』を参照してください。

パッケージの場合

パッケージに関する推奨事項は、次のとおりです。
  • 異なるプロジェクトまたは異なるソース・ディレクトリーで、同じパッケージ名は使用しない
  • デフォルト・パッケージは使用しない

パーツ割り当て

パーツの場合には、推奨事項の多くは役立つ例であり、困難な要件ではありません。 別の方法で行う正当な理由がない場合には、以下のオプションの推奨事項も実行してください。
  • PageHandlers を使用する場合の要件 は、関連付けされている PageHandler と 同じプロジェクトに JSP を配置することです。
  • 生成不可能なパーツ (レコード・パーツなど) が、1 つのプログラム、ライブラリー、または PageHandler でのみ使用される場合は、使用する側のパーツと同じファイル内にその生成不可能なパーツを配置してください。
  • パーツが同じパッケージ内の異なるファイルから参照される場合は、そのパッケージ内の別のファイルにそのパーツを配置します。
  • パーツが単一プロジェクト内のパッケージ間で共用される場合は、そのプロジェクト内の別のパッケージにそのパーツを配置します。
  • 完全に無関係なアプリケーションのコードは、異なるプロジェクトに配置します。 プロジェクトは、ローカル・ディレクトリー構造とリポジトリー間でコード転送を行う単位です。 開発者が開発システムにロードする必要があるコードの量を最小化できるようにプロジェクト構造を設計します。
  • プロジェクト、パッケージ、およびファイルに、それらに含まれるパーツの使用法を反映した名前を付けます。
  • プロセスで開発者のコード所有権が主張されている場合は、所有者が異なるパーツを同じファイルに割り当てないでください。
  • パッケージの目的を明確に理解してから、パッケージにパーツを割り当てます。 また、パーツ間の関係の緊密度に応じてパーツをグループ化します。
    以下の特徴は重要です。
    • 同一のパッケージ内でファイルからファイルへパーツを移動するために、他のファイルの import 文を変更する必要はありません。
    • 1 つのパッケージから他のパッケージへパーツを移動する場合は、移動するパーツを参照するすべてのファイルに、 import 文を追加するか、または変更する必要がある場合があります。
フィードバック
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.