このセクションでは、アプリケーション・ビルダーの基本概念を説明します。アプリケーション・ビルダーを使用すると、表やプロシージャなどのデータベース・オブジェクトの外観としてHTMLインタフェース(またはアプリケーション)を構築できます。各アプリケーションは、タブ、ボタンまたはハイパーテキスト・リンクを使用して相互にリンクされたページの集合です。
このセクションの内容は次のとおりです。
ページは、アプリケーションの基本的なビルディング・ブロックです。アプリケーション・ビルダーでアプリケーションを構築する際は、タブ、リスト、ボタン、アイテム、リージョンなどのユーザー・インタフェース要素を含むページを作成します。
ページ定義上のページにコントロールを追加します。
既存のページのページ定義を表示するには、次のステップを実行します。
「作業領域」ホームページにナビゲートします。
「アプリケーション・ビルダー」アイコンをクリックします。
アプリケーションを選択します。
ページを選択します。
「ページ定義」が次の3つの主要セクションに分かれて表示されます。
ページ・レンダリング: ページのレンダリング中に実行されるユーザー・インタフェース・コントロールおよびロジックがリストされます。ページ・レンダリングとは、データベースからのページ生成プロセスです。「ページ・レンダリングについて」を参照してください。
ページ・プロセス: ページの処理中に評価および実行されるロジック・コントロール(計算やプロセスなど)がリストされます。詳細は、「ページ・プロセスについて」を参照してください。
共有コンポーネント: アプリケーションの1つ以上のページで使用可能な共通のコンポーネントをリストします。詳細は、「共有コンポーネントについて」を参照してください。
アプリケーション・ビルダーにアプリケーションを作成する際に、タブ、ボタンまたはハイパーテキスト・リンクを使用して複数のページをリンクできます。各ページにはボタンおよびアイテムを配置でき、アプリケーション・ロジックを含めることができます。ページでは、条件付きナビゲーションを使用したあるページから次のページへのブランチ、計算および検証の実行、およびレポート、カレンダおよびチャートの表示を行うことができます。組込みウィザードを使用してレポート、チャートおよびフォームを生成したり、静的HTMLを生成したり、PL/SQLプログラミングによってカスタム・レンダリングを行うことができます。
このセクションの構成は次のとおりです。
Application Expressエンジンは、Oracleのデータベース表に格納されたデータに基づいて、ページを動的にレンダリングおよび処理します。レンダリングされたアプリケーションを表示するには、Application Expressエンジンにそのアプリケーションをリクエストします。アプリケーションを実行すると、Application Expressエンジンによって次の2つのプロセスが使用されます。
ページ表示は、ページ・レンダリング・プロセスです。このプロセスによって、すべてのページ属性(リージョン、アイテム、ボタンなど)が表示可能なHTMLページに編成されます。
ページ受入れでは、ページの処理が行われます。このプロセスによって、すべての計算、検証、プロセスおよびブランチが実行されます。
URLを使用してページをリクエストする場合、エンジンはページ表示を実行します。ページを送信する場合、Application Expressエンジンはページ受入れを実行するか、送信した値をセッション・キャッシュに保存して、計算、検証または処理を行う間はページ・プロセスを実行します。
条件とは、リージョン、アイテム、ボタンおよびタブの表示と、プロセス、計算および検証の実行を制御するために役立つ論理単位です。たとえば、ボタンに条件を適用すると、レンダリング・エンジンによって、レンダリング(ページ表示)プロセス中にその条件が評価されます。条件に合格するかどうかによって、そのページ・コントロール(この場合はボタン)が表示されるかどうかが決まります。
条件を指定するには、条件タイプを選択します。条件タイプは、コントロールまたはコンポーネントを最初に作成するときに選択するか、コントロールまたはコンポーネントを編集する場合に条件タイプ属性から選択します。選択した条件タイプに応じて、「式」フィールドに適切な値を入力します。条件は、「式」フィールドに入力した値に基づいて、trueまたはfalseに評価されます。
注意: 「式」フィールドを使用するかどうかは、選択した条件タイプによって決まります。いずれのフィールドの値も必要としない条件タイプ、「式1」の値のみが必要な条件タイプ、両方のフィールドの値が必要な条件タイプなどがあります。これらのフィールドは「式1」および「式2」とラベル付けされていますが、指定した条件タイプの値が式という用語の公式の定義に準拠していない場合があります。これらの値は、選択した条件タイプに適したテキスト値です。 |
任意のコンポーネントまたはコントロールに使用可能なすべての条件のリストを表示するには、「条件タイプ」リストの右側にある矢印をクリックします。リストのすぐ下に、一般的な選択項目へのショートカットが表示されます。条件に式が必要な場合は、該当するフィールドにその式を入力します。
次のセクションでは、一般的に使用されるいくつかの条件タイプについて説明します。
式1のカレント・ページは、カレント・ページ番号が、「式1」内のカンマで区切られたページ・リストに含まれている場合にtrueと評価されます。次に例を示します。
3,100,203
カレント・ページが100である場合、この条件はtrueに評価され、条件に合格します。
「存在する(SQL問合せが1行以上を戻す)」は、SQL問合せとして表現されます。問合せで1行以上が戻される場合、この条件はtrueと評価されます。次に例を示します。
SELECT 1 FROM employees WHERE department_id = :P101_DEPTNO
この例では、アイテムP101_DEPTNO
がバインド変数として参照されます。アプリケーション・プロセスおよびSQL問合せリージョン内でバインド変数を使用すると、アイテムのセッション・ステートを参照できます。P101_DEPTNO
の値に指定した部門に1人以上の従業員が存在する場合、この条件はtrueと評価されます。
認証は、ユーザーがアプリケーションにアクセスする前に、そのユーザーのアイデンティティを証明するプロセスです。認証では、ユーザーがユーザー名とパスワードを入力するか、またはデジタル証明書や保護キーを使用する場合があります。
Oracle Application Expressは、モジュール認証をサポートしているため、必要に応じて認証メソッドを簡単に切り替えられます。ユーザー・アイデンティティの証明は、複数の組込み認証メソッドから選択するか、またはウィザードを使用して独自のカスタム認証方法を作成して実行できます。
条件はページ上の特定のコントロールまたはコンポーネントのレンダリングおよび処理を制御しますが、認可スキームはユーザーのアクセスを制御します。認可は、ユーザー権限に基づいてリソースへのアクセスを制御することを示す広義語です。
認可スキームは、アプリケーションの認証スキームのセキュリティを強化します。認可スキームは、アプリケーション全体、各ページ、またはリージョン、アイテム、ボタンなどの特定のページ・コントロールに対して指定できます。たとえば、認可スキームを使用して、ユーザーに表示するタブ、リージョンまたはナビゲーション・バー・エントリを選択的に決定できます。
HTTP(HTMLページの配布に最も一般的に使用されるプロトコル)は、ステートレスなプロトコルです。Webブラウザは、ページ全体をダウンロードするために必要な時間のみサーバーに接続します。また、サーバーでは、各ページ・リクエストは、発生済または将来発生する他のページ・リクエストと関連しない個別のイベントとして処理されます。これは、あるページで入力したフォーム値に後続のページでアクセスするには、なんらかのセッション・ステート管理を使用する必要があることを意味します。通常、ユーザーがあるページのフォームに入力した値には、後続のページからはアクセスできません。Oracle Application Expressは透過的にセッション・ステートを保持するため、開発者は、アプリケーションの任意のページでセッション・ステートの値を取得および設定できます。
このセクションの構成は次のとおりです。
セッションは、ページ・ビュー間で永続性(またはステートフルな動作)を確立する論理的な構成体です。各セッションには、一意の識別子が割り当てられています。Application Expressエンジンは、この識別子(セッションID)を使用して、各ページ・ビューの前後に、アプリケーションで作業中のデータ・セット(セッション・ステート)を格納および取得します。
個々のセッションは相互に完全に独立しているため、任意の数のセッションがデータベース内に同時に存在できます。セッションは管理者によって消去されるまでデータベース内で存続するため、ユーザーは、以前のセッションに戻ることができ、1つのアプリケーションを長期間実行し続けることができます。また、ユーザーは複数のブラウザ・セッションで、アプリケーションの複数のインスタンスを同時に実行できます。
セッションは、ページ・リクエストの処理に使用されるOracleのデータベース・セッションとは論理的にも物理的にも異なります。ユーザーはアプリケーションを、1つのOracle Application Expressセッションで、ログインからログアウトまで実行します。この期間は、通常分単位か時間単位です。このセッション中にページがリクエストされるたびに、Application ExpressエンジンはOracleのデータベース・セッションを作成または再利用してデータベース・リソースにアクセスします。多くの場合、これらのデータベース・セッションは、数分の1秒のみ存続します。
参照: Oracle Application Express管理ガイドの「アクティブ・セッションの表示」を参照してください。 |
Application Expressエンジンは、ページ・リクエストごとにユーザーのアイデンティティ(または匿名性)を証明し、データベースからセッション・ステートをフェッチするためにセッションIDを確立します。セッションIDが最もわかりやすく表示されている場所は、ページ・リクエストのURLです。URLの第3パラメータとしてセッションIDが表示されます。次に例を示します。
http://apex.oracle.com/pls/apex/f?p=4350:1:220883407765693447
この例では、セッションIDは220883407765693447です。
他にわかりやすく表示されている場所は、ページのHTML POSTデータです。また間接的にはセッションCookieのコンテンツです。このCookieは、認証時にApplication Expressエンジンによって送信され、アプリケーション(またはブラウザ)セッションの存続中、維持されます。
Oracle Application Expressは、認証プロセス中に新しいセッションIDを割り当て、認証されたユーザーのアイデンティティをセッションIDとともに記録し、続けて各ページ・リクエストのURLまたはPOSTデータをセッションのCookieおよびデータベースのセッション・レコードと照合して確認します。この確認によって、柔軟性とセキュリティが向上します。
セッションIDがセッション・ステート用のキーであるのに対し、セッションのCookie(使用される場合)およびセッション・レコードは、セッションIDとユーザーの認証ステータスの整合性を保証します。
Oracle Application Expressアプリケーションの動作は、通常、セッション・ステートの値によって決まります。たとえば、ボタンは、アイテムのセッション・ステートの値に基づいて、条件付きで表示できます。ページのセッション・ステートを表示するには、開発者ツールバーの「セッション」をクリックします。
セッション・ステート・ページは、現在実行中のアプリケーションのセッションに関する有益な情報を提供します。特定のページを検索するには、ページ・フィールドにページ番号を入力して「実行」をクリックします。表3-1に、セッション・ステート・ページで参照可能な様々な情報を示します。
表3-1 セッション・ステート・ページで参照可能な情報
ヘッダー | 説明 |
---|---|
アプリケーション |
アプリケーションの名前を表示します。 |
セッション |
カレント・セッションのセッション・ステートのサマリーを表示します。 |
ユーザー |
現行ユーザーを表示します。 |
作業領域 |
現行の作業領域IDを表示します。 |
ブラウザ言語 |
現行のブラウザ言語を表示します。 |
ページ・アイテム |
アプリケーションID、ページ番号、アイテム名、アイテムの表示方法(チェック・ボックス、日付ピッカー、表示のみ、テキスト・フィールド、非表示、ポップアップ、ラジオ・グループなど)、セッション・ステートのアイテム値、ステータスなどのページ・アイテムの属性が表示されます。 「ステータス」列には、セッション・ステートのステータスが示されます。表示される値を次に示します。
|
アプリケーション・アイテム |
アプリケーション・アイテムは、ページに存在しないアイテムです。アプリケーション・アイテムは、関連付けられたユーザー・インタフェース・プロパティを持たないセッション・ステート変数です。 参照: アイテム値を参照する方法については、「アプリケーション・レベル・アイテムの理解」および「置換文字列の理解」を参照してください。 |
インタラクティブな、データに応じて動作するWebアプリケーションを構築するには、セッション・ステート値にアクセスして管理する機能が重要です。Oracle Application Expressでは、セッション・ステートはページごとに自動的に管理され、静的HTML、またはプロセスや検証などのロジック・コントロールによって簡単に参照できます。
このセクションの構成は次のとおりです。
アイテムの値の参照は、セッション・ステートの参照の最も一般的な例です。アイテムはフィールド、テキスト領域、パスワード、選択リスト、チェック・ボックスなどです。表3-2に、アイテム値を参照するためにサポートされている構文を示します。
表3-2 アイテム値を参照するための構文
タイプ | 構文 | 説明 |
---|---|---|
SQL |
|
名前が30文字以下のアイテム用の標準のバインド変数構文。この構文は、SQL問合せおよびPL/SQL内の参照用に使用します。 |
PL/SQL |
|
参照:Oracle Application Express APIリファレンス |
PL/SQL |
|
参照:Oracle Application Express APIリファレンス |
静的テキスト(完全置換) |
|
静的テキスト。完全置換です。 |
ページがユーザーによって送信されると、Application Expressエンジンは、フィールド(アイテム)に入力された値をセッション・ステートに自動的に格納します。たとえば、2つのページを持つアプリケーションが存在すると想定します。このアプリケーションの最初のページには、ユーザーが電話番号を入力できるフォームが含まれています。このフォームは、P2_PhoneNo
という名前のアイテムを作成して定義しています。2番目のページには、ユーザーがフォームに入力する情報を表示する必要があります。
このページが送信されると、Oracle Application Expressによって、電話番号フィールドに入力された値が取得され、今後使用するためにその値が格納されます。ユーザーが入力した電話番号は、そのページのフィールドに関連付けられたアイテムを参照することで、セッション・ステートから取得できます。
アプリケーションの開発時に、特定のアイテム、ページ上のすべてのアイテム、アプリケーション内のすべてのページ、または現行のユーザー・セッション用にキャッシュされた値をクリアする必要がある場合があります。キャッシュされた値をクリアすると、その値がNULLにリセットされます。次のトピックでは、セッション・ステートをクリアする具体的な例について説明します。
このセクションの構成は次のとおりです。
1つのアイテムのキャッシュをクリアすると、そのアイテムの値がNULLにリセットされます。たとえば、ページがレンダリング用に準備されるときに特定のアイテムの値を確実にNULLにしておく必要がある場合に、この方法を使用します。
次の例では、標準f?p
構文を使用してアイテムのキャッシュをクリアします。この例では、アプリケーション100のページ5がコールされます。f?p
構文のClearCache
位置にMY_ITEM
を指定すると、MY_ITEM
の値がNULL
にリセットされます。
f?p=100:5:&APP_SESSION.::NO:MY_ITEM
次の例では、アイテムTHE_EMPNO
およびTHE_DEPTNO
の値がリセットされます。
f?p=100:5:&APP_SESSION.::NO:THE_EMPNO,THE_DEPTNO
アプリケーション・アイテムをキャッシュすると、セッション・ステートを効率的に保持できます。ただし、ページ上のすべてのアイテムのキャッシュをクリアする必要がある場合もあります。たとえば、ユーザーが新しい注文を作成するリンクをクリックすると、ページ上のすべてのフィールドがクリアされるようにする必要があると想定します。ページ全体のキャッシュをクリアすることで、ページ上のすべてのアイテムの値をNULLに設定できます。
この例では、2つのページのセッション・キャッシュがクリアされ、ページ区切りがリセットされます。
f?p=6000:6003:&APP_SESSION.::NO:RP,6004,6014
この例について説明します。
アプリケーション6000のページ6003が実行され、現行のセッションIDが使用されます。
デバッグ情報を表示しないように指示されます(NO
)。
カレント・セッションのキャッシュに保持されたページ6004および6014のアイテムのすべての値がクリアされます。
ページ6003(リクエストされたページ)のリージョンのページ区切り(RP
)がリセットされます。
この例では、更新フォームの実装方法を示します。既存の情報をクリアし、アイテムの値(通常、主キー)を設定します。
f?p=6000:6003:&APP_SESSION.::NO:6003:MY_ITEM:1234
この例について説明します。
アプリケーション6000のページ6003が実行され、現行のセッションIDが使用されます。
デバッグ情報を表示しないように指示されます(NO
)。
カレント・セッションのキャッシュに保持されたページ6003のアイテムのすべての値がクリアされます。
MY_ITEM
というアイテムのセッション・ステートの値を1234
に設定します。
この例は、値が複数のアイテムに渡されること以外は、前述の例に類似しています。
f?p=6000:6004:&APP_SESSION.::NO:6003:MY_ITEM1,MY_ITEM2,MY_ITEM3:1234,,5678
この例について説明します。
アプリケーション6000のページ6004が実行され、現行のセッションIDが使用されます。
ページ6003のアイテムのカレント・セッションのキャッシュがクリアされます。
デバッグ情報を表示しないように指示されます(NO
)。
MY_ITEM1
の値が1234、MY_ITEM2
の値がNULL(プレースホルダとして使用されたカンマによって示される)およびMY_ITEM3
の値が5678に設定されます。
アプリケーション・キャッシュは、f?p
構文を使用し、キーワードAPP
を使用してClear Cache引数を作成することでクリアできます。次に例を示します。
f?p=App:Page:Session::NO:APP
注意: アプリケーション全体のキャッシュをリセットしても、アプリケーションは完全なリセット状態にはリストアされません。たとえば、アプリケーションに新しいインスタンス開始時の計算やプロセスが含まれている場合、Application Expressエンジンは、該当するアプリケーション・セッションが作成されたときに、これらの計算やプロセスを実行します。その後、キャッシュのクリア・リクエストを処理し、リクエストされたページを表示します。(セッションIDの追跡にCookieが使用されていない場合に)セッションIDを指定せずにアプリケーションを完全にリセットするには、セッションIDを指定せずにURLを使用するか、または別のアプリケーションから |
バインド変数構文は、指定したアイテムのセッション・ステートを参照するためにOracle Application ExpressでSQLまたはPL/SQLを使用する場合はいつでも使用できます。次に例を示します。
SELECT * FROM employees WHERE last_name like '%' || :SEARCH_STRING || '%'
この例では、検索文字列がページ・アイテムです。リージョン・タイプがSQL問合せとして定義されている場合、標準SQLバインド変数構文を使用して値を参照できます。バインド変数を使用すると、解析済のSQL問合せがデータベースによって再利用されるため、サーバーによるメモリーの使用が最適化されます。
バインド変数構文を使用する場合は、次の規則に注意してください。
バインド変数名は、アイテム名に対応している必要があります。
バインド変数名は、大/小文字が区別されません。
バインド変数名は、30文字以下である必要があります(有効なOracle識別子である必要があります)。
ページ・アイテム名とアプリケーション・アイテム名は255文字以下に設定できますが、アプリケーション・アイテムをバインド変数構文を使用したSQL内で使用する場合、そのアイテム名は30文字以下で指定する必要があります。
リージョン・タイプがSQL問合せ、SQL問合せ(SQL問合せを戻すPL/SQLファンクション本体)、またはLOVとして定義されている場合は、次の構文を使用してセッション・ステートを参照できます。
:MY_ITEM
これを行うための一般的な方法の1つは、セッション・ステート変数をWHERE句
に組み込むことです。次の例では、アイテムTHE_DEPTNO
の値を、SQL問合せから定義されるリージョンにバインドする方法を示します。
SELECT last_name, job_id, salary FROM employees WHERE department_id = :THE_DEPTNO
PL/SQLプロシージャとして定義されたリージョン・タイプは、PL/SQL無名ブロック構文を使用して作成されます。つまり、PL/SQLブロックを囲むために開始キーワードおよび終了キーワードが使用されます。次に例を示します。
IF
:P1_JOB IS NOT NULL THEN INSERT INTO employees (employee_id, first_name, job_id) VALUES (:P1_EMP_ID
, :P1_NAME, :P1_JOB) end if;
この例では、employee_id
、first_name
およびjob_id
の値には、P1_EMP_ID
、P1_NAME
およびP1_JOB
の値が移入されます。
ページごとに表示されるURLは、Oracle Application Expressの場所、Oracle Application Expressのアドレス、アプリケーションID、ページ番号およびセッションIDを指定します。
アプリケーションIDは各アプリケーションを識別する一意の番号です。同様に、ページ番号は各ページを一意に識別します。アプリケーションおよびページには、英数字の別名がある場合もあります。アプリケーションの別名は作業領域内で一意であり、ページの別名は各アプリケーション内で一意です。アプリケーションを実行する場合、Application Expressエンジンはユーザーのセッション・ステートに対するキーとして機能するセッション番号を生成します。
このセクションの構成は次のとおりです。
ページごとに表示されるURLは、Oracle Application Expressの場所を指定します。また、Oracle Application Expressのアドレス、アプリケーションID、ページ番号およびセッションIDを指定します。次に例を示します。
http://apex.oracle.com/pls/apex/f?p=4350:1:220883407765693447
この例の内容は次のとおりです。
apex.oracle.com
は、サーバーのURLです。
pls
は、mod_plsql
カートリッジを使用するためのインジケータです。
apex
は、データベース・アクセス記述子(DAD)名です。DADにはHTTP Serverからデータベース・サーバーへの接続方法が記述されているため、HTTPリクエストを実行できます。デフォルト値はapex
です。
f?p=
は、Oracle Application Expressによって使用される接頭辞です。
4350
は、コールされているアプリケーションです。
1
は、表示されるアプリケーション内のページです。
220883407765693447
は、セッション番号です。
アプリケーションのページ間にリンクを作成するには、次の構文を使用します。
f?p=App:Page:Session:Request:Debug:ClearCache:itemNames:itemValues:PrinterFriendly
表3-3に、f?p
構文の使用時に指定できる引数を示します。
表3-3 f?p構文の引数
構文 | 説明 |
---|---|
|
アプリケーションIDまたは英数字の別名を指定します。 |
|
ページ番号または英数字の別名を指定します。 |
|
セッションIDを指定します。セッションIDを参照して、セッション番号を渡すことで同じセッション・ステートを保持している他のページへのハイパーテキスト・リンクを作成できます。セッションIDを参照するには、次の構文を使用します。
|
|
|
|
アプリーション処理の詳細を表示します。DEBUGフラグの有効値は
参照: 「アプリケーションのデバッグ」 |
|
キャッシュをクリアします。これによりアイテムの値がNULLに設定されます。 キャッシュされたアイテムを単一のページでクリアするには、数値ページ番号を指定します。キャッシュされたアイテムを複数のページでクリアするには、ページ番号のカンマ区切りのリストを使用します。ページのキャッシュをクリアすると、ページのステートフル・プロセスもリセットされます。個別の値またはカンマ区切りの値には、リセットするコレクション名を追加することや、リクエストされたページにおけるリージョンのページ区切りをリセットするためにキーワード 参照: 「セッション・ステートのクリア」 |
|
URLでセッション・ステートを設定するために使用される、カンマで区切られたアイテム名のリストです。 |
|
URLでセッション・ステートを設定するために使用されるアイテム値のリストです。アイテム値にコロンを含めることはできませんが、カンマをバックスラッシュで囲んで指定することは可能です。アイテム値にカンマを渡すには、文字をバックスラッシュで囲んでください。次に例を示します。 \123,45\ |
|
ページを「印刷用」モードでレンダリングするかどうかを決定します。PrinterFriendlyが「はい」に設定されている場合は、ページが「印刷用」モードでレンダリングされます。PrinterFriendlyの値は、リージョンなどの要素をページから削除して印刷される出力を最適化するための条件のレンダリングに使用されます。印刷用プリファレンスを参照するには、次の構文を使用します。 V('PRINTER_FRIENDLY') 参照時は、Application Expressエンジンはタブやナビゲーション・バーを表示しません。すべてのアイテムは、フォーム要素ではなくテキストで表示されます。 |
f?p
構文の動作を理解することは重要ですが、この構文をユーザー自身が構築する必要がある場合はほとんどありません。アプリケーション・ビルダーには、これらの参照を自動的に作成する多くのウィザードが含まれています。次のセクションでは、f?p
構文を使用してページをリンクする多くの具体的な場合について説明します。
アプリケーションおよびページの別名は、有効なOracle識別子で構成する必要があります。空白を含めることはできず、また大/小文字は区別されません。次の例では、アプリケーション内から、アプリケーションおよびページの別名を使用してページをコールします。アプリケーションmyapp
のページhome
が実行され、現行のセッションIDが使用されます。
f?p=myapp:home:&APP_SESSION.
アプリケーションの別名は、作業領域内で一意である必要があります。異なる作業領域のアプリケーションに同じアプリケーション別名がある場合は、&c
引数を使用して作業領域名を指定します。次に例を示します。
f?p=common_alias:home:&APP_SESSION.&c=WORKSPACE_A
ボタンの作成時に、ユーザーがそのボタンをクリックするとリダイレクトされるURLを指定できます。この例では、アプリケーション6000のページ6001が実行され、現行のセッションIDが使用されます。
f?p=6000:6001:&APP_SESSION.
これは、ボタンを使用するための唯一の方法です。この方法は、ページの送信を省略し、そのページ上のハイパーリンクとして機能します。他にも、まずページを送信する方法があります。その方法では、ボタンをクリックすると、処理するページが送信され、フォームが送信された後、セッション・ステートが保存されます。
アプリケーション内のページが公開されていて認証の必要がない場合、セッションIDとしてゼロを使用することで、アプリケーション・ユーザーは容易にページをブックマークできます。
認証の必要がないアプリケーション・ページは、セッションIDがゼロ(単一の数字0
)であるf?q URLを使用してアクセスできます。ブラウザにURLを入力するか、またはセッションIDに0
を含むリンクをクリックしてページをリクエストすると、Application Expressエンジンは新しいセッションIDを割り当て、新しいセッションIDを含むセッションCookieをブラウザに送信します。アプリケーションのパブリック・ページを介してナビゲートすると、パブリック・ページへの生成済リンクすべてにセッションID0
が含まれており、パブリック・ページへのブランチすべてに、表示されているセッションIDに0
を使用する新しいURLが含まれていることがわかります。ただし、実際には、Application Expressエンジンは、バックグラウンドでカレント・セッションIDとしてCookieのセッションIDを使用してセッション・ステートを指定します。
カレント・セッションIDを非表示にする場合にこの機能は有効です。セッションIDを非表示にすると、ブックマーク・リンクにセッションIDを含めなくてもページをブックマークできるようになります。さらに優れた点として、セッションIDにゼロを使用すると、実際のセッションIDを検索エンジンから見えないようにします。
アプリケーションのセッションIDとしてゼロを使用するには、ゼロ・セッションIDを含むリンクを少なくとも1つ生成する必要があります。このリンクを使用することでゼロ・セッションIDメカニズムが開始されます。1つの方法として、アプリケーションのホームページでゼロ・セッションIDを含む単一の静的リンクを提供する方法があります。たとえば、通常はページ2へのリンクにf?p=&APP_ID.:2:&APP_SESSION
をコード化するところで、f?p=&APP_ID.:2:0
をコード化します。
ページ・テンプレート内またはリージョン・ソース内で置換文字列を使用すると、文字列を別の値に置換できます。ユーザーによるアイテムの編集を可能にするアプリケーションを設計するには、情報を渡すために置換文字列を使用します。
このセクションの構成は次のとおりです。
アプリケーション・ビルダーでは、次のように置換文字列を使用できます。
コンポーネント値を参照するために置換文字列をテンプレート内に含めます。
&ITEM
構文を使用して、ページまたはアプリケーション・アイテムを参照します。
組込み置換文字列を使用して、特定のタイプの機能を実現します。
テンプレート内で使用可能な特別な置換文字列は、シャープ記号(#)で示します。次に例を示します。
#ABC#
置換変数を使用してページまたはアプリケーション・アイテムを参照するには、次のステップを実行します。
アイテム名の先頭にアンパサンド(&)を追加します。
アイテム名の末尾にピリオド(.)を追加します。
たとえば、HTMLリージョン、リージョン・タイトル、アイテム・ラベル、または静的テキストを使用するその他の多数のコンテキストでF101_X
という名前のアプリケーション・アイテムを参照する場合は、次のように入力します。
&F101_X.
最後にピリオドが必要であることに注意してください。ページが表示されるとき、Application Expressエンジンによって、置換文字列の値がアイテムF101_X
の値に置き換えられます。
テンプレートの定義を表示することによって、テンプレート固有のどの置換文字列がどのテンプレートでサポートされるかを確認できます。詳細は、「テンプレートのカスタマイズ」を参照してください。
アプリケーション・ビルダーでは、多くの組込み置換文字列がサポートされています。これらの値を参照して特定のタイプの機能を実行できます。
次のセクションでは、これらの置換文字列について、使用する状況および現在サポートされている構文を説明します。バインド変数:USER
はデータベース内で特別な意味を持つことに注意してください。また、直接PL/SQLという用語は、プロシージャおよびファンクションなどのストアド・データベース・オブジェクトで使用可能なPL/SQLを表します。
このセクションの構成は次のとおりです。
APP_ALIAS
は、カレント・アプリケーションの英数字の名前です。APP_ALIAS
は、APP_ID
が1つのデータベースでホスティングされているすべての作業領域およびすべてのアプリケーションで一意である必要があるという点で、APP_ID
と異なります。APP_ALIAS
は、作業領域内で一意である必要があります。たとえば、1つのAPP_ALIAS
を使用して2つの異なる作業領域にABCというアプリケーションを作成することができます。APP_ALIAS
は、APP_ID
を使用できる場所であればほぼすべての場合に使用できます。たとえば、次の例に示すように、f?p
構文にAPP_ALIAS
またはアプリケーションIDを使用できます。
f?p=ABC:1:&APP_SESSION.
この例では、アプリケーションABCのページ1が、カレント・セッションを使用して実行されます。
表3-4に、APP_ALIAS
を参照するためにサポートされている構文を示します。
次に、HTMLの例を示します。
Click me to go to page 1 <a href="f?p=&APP_ALIAS.:1:&APP_SESSION."> of the current application</a>
APP_ID
は、現在実行されているアプリケーションのアプリケーションIDを示します。表3-5に、APP_ID
を参照するためにサポートされている構文を示します。
表3-5 APP_ID構文
参照タイプ | 構文 |
---|---|
バインド変数 |
|
直接PL/SQL |
|
PL/SQL |
|
置換文字列 |
|
次に、置換文字列の参照の例を示します。
f?p=&APP_ID.:40:&APP_SESSION.
この置換文字列を使用して、特定のアプリケーションに固有で、複数のアプリケーションでは共有されていないアップロードされたイメージ、JavaScriptおよびカスケード・スタイルシートを参照します。ファイルをアップロードして、そのファイルをアプリケーション固有に設定した場合は、この置換文字列またはバインド変数を使用する必要があります。表3-6に、APP_IMAGES
を参照するためにサポートされている構文を示します。
APP_PAGE_ID
はカレント・アプリケーションIDです。たとえば、アプリケーションが3ページ目に存在した場合、結果は3になります。この構文の使用は、複数のアプリケーションで汎用的に動作する必要があるアプリケーション・コンポーネントを記述する場合に有効です。表3-7に、APP_PAGE_ID
を参照するためにサポートされている構文を示します。
表3-7 APP_PAGE_ID構文
参照タイプ | 構文 |
---|---|
バインド変数 |
|
PL/SQL |
|
PL/SQLおよび直接PL |
|
置換文字列 |
|
次に、置換文字列の参照の例を示します。
f?p=&APP_ID.:&APP_PAGE_ID.:&APP_SESSION.
APP_SESSION
は、最もよく使用される組込み置換文字列の1つです。この置換文字列を使用して、セッション番号を渡すことによりセッション・ステートを維持するアプリケーション・ページ間のハイパーテキスト・リンクを作成できます。APP_SESSION
のかわりに置換文字列SESSION
を使用することもできます。表3-8に、APP_SESSION
を参照するためにサポートされている構文を示します。
表3-8 APP_SESSION構文
参照タイプ | 構文 |
---|---|
バインド変数 |
|
PL/SQL |
|
短縮PL/SQL |
|
置換文字列 |
|
次に例を示します。
HTMLリージョン内からの参照:
<a href="f?p=100:5:&APP_SESSION.">click me</a>
PL/SQLを使用した参照:
htf.anchor('f?p=100:5:'||V('APP_SESSION'),'click me');
SQL問合せを使用した参照:
SELECT htf.anchor('f?p=100:5:'||:APP_SESSION,'clickme') FROM DUAL;
APP_UNIQUE_PAGE_ID
は、各ページ・ビューに固有なOracle順序から生成される整数です。この数値は、アプリケーションでの重複ページの送信を防止するために使用され、その他の用途にも使用できます。たとえば、ブラウザのキャッシュの問題を防止するために一意のURLを作成する場合、この数値を、f
プロシージャへのコール内のリクエスト列またはデバッグ列に埋め込むことができます。表3-9に、APP_UNIQUE_PAGE_ID
を参照するためにサポートされている構文を示します。
表3-9 APP_UNIQUE_PAGE_ID構文
参照タイプ | 構文 |
---|---|
バインド変数 |
|
PL/SQL |
|
置換文字列 |
|
次に、HTMLの例を示します。
SELECT 'f?p=100:1:'||:APP_SESSION||':'||:APP_UNIQUE_PAGE_ID|| ':::P1_EMPNO:'||employee_id, first_name, job_id FROM employees
リクエスト列にAPP_UNIQUE_PAGE_ID
が使用されていることに注意してください。これによって、このURLが一意になり、ブラウザによる過度のキャッシュの問題を回避できます。
APP_USER
は、アプリケーションを実行しているカレント・ユーザーです。認証モデルに応じて、ユーザーの値の設定も異なります。アプリケーションがデータベース認証を使用して実行されている場合、ユーザーの値はデータベースの擬似列USERと同じになります。アプリケーションが、ユーザー認証を必要とする認証スキームを使用する場合、APP_USER
の値はその認証スキームによって設定され、通常は、認証時に使用されるユーザー名に設定されます。表3-10に、APP_USER
を参照するためにサポートされている構文を示します。
次に例を示します。
HTMLリージョン内からの参照:
Hello you are logged in as &APP_USER.
PL/SQLを使用した参照:
htp.p('Hello you are logged in as'||V('APP_USER'));
バインド変数としての参照:
SELECT * FROM some_table WHERE user_id = :APP_USER
このアプリケーション・レベルの属性は、有効な認証済接頭辞(ログインしているURLの接頭辞)を示します。相対パスまたはhttp
で始まるフルパスを使用できます。このアイテムは、アプリケーションが認証済(ログイン済)モードとパブリック(未ログイン)・モードの両方で実行可能な場合に有効です。AUTHENTICATED_URL_PREFIX
を使用すると、認証済のページへのリンクを作成できます。このアイテムは、Basicデータベース認証の使用時に最も有効です。これは、URLの変更に認証が必要になる場合があるためです。表3-11に、AUTHENTICATED_URL_PREFIX
を参照するためにサポートされている構文を示します。
BROWSER_LANGUAGE
は、Webブラウザの現行の言語プリファレンスを参照します。表3-12に、BROWSER_LANGUAGE
を参照するためにサポートされている構文を示します。
CURRENT_PARENT_TAB_TEXT
は、ページ・テンプレートで最も有効です。ただし、この文字列は、2つのレベルのタブ(親タブと標準タブ)が使用されるアプリケーションでのみ使用できます。この文字列は、親タブ・ラベルの参照に使用します。この置換文字列を使用すると、現在選択されている親タブを、ページ・テンプレート内で繰り返すことができます。表3-13に、CURRENT_PARENT_TAB_TEXT
を参照するためにサポートされている構文を示します。
DEBUG
フラグの有効値はYesまたはNoです。デバッグを有効にすると、アプリケーション・プロセスの詳細が表示されます。カスタム・コードを記述する場合は、デバッグ・モードがYesに設定されている場合にのみデバッグ情報を生成できます。表3-14に、DEBUG
を参照するためにサポートされている構文を示します。
表3-14 DEBUG構文
参照タイプ | 構文 |
---|---|
バインド変数 |
: |
直接PL/SQL |
|
PL/SQL |
|
置換文字列 |
|
次に、DEBUG
の現行の値を保持する置換文字列の参照の例を示します。
f?p=100:1:&APP_SESSION.::&DEBUG
HOME_LINK
は、アプリケーションのホームページです。ページが指定されておらず、かつ認証スキームのロジックによって代替ページが指定されていない場合、Application Expressエンジンによって、この場所にリダイレクトされます。HOME_LINKはアプリケーション属性ページで定義します。
表3-15に、HOME_LINKを参照するためにサポートされている構文を示します。
表3-15 HOME_LINK構文
参照タイプ | 構文 |
---|---|
直接PL/SQL |
|
PL/SQL |
|
テンプレート参照 |
|
置換文字列 |
|
現在ログインしていないユーザーのためにログイン・ページへのリンクを表示するには、LOGIN_URL
を使用します。表3-16に、LOGIN_URL
を参照するためにサポートされている構文を示します。
IMAGE_PREFIX
の値によって、Oracle Application Expressによって配布されたイメージ・ディレクトリを指すためにWebサーバーが使用する仮想パスが決まります。アップロードされたイメージを参照する場合は、WORKSPACE_IMAGES
およびAPP_IMAGES
を使用します。表3-17に、IMAGE_PREFIX
を参照するためにサポートされている構文を示します。
PL/SQLコードからアプリケーションへのコールを生成する場合、Oracle Application Expressスキーマの所有者を参照する必要がある場合があります。次に、直接PL/SQLを参照する際の正しい構文を示します。
APEX_APPLICATION.G_FLOW_SCHEMA_OWNER
また、#FLOW_OWNER#
を使用してSQL問合せおよびPL/SQL(リージョンやプロセスなど)でこの値を参照することもできます。
PRINTER_FRIENDLY
の値によって、Application Expressエンジンが印刷表示モードで実行するかどうかが決まります。この設定は、印刷されたドキュメントに不要な要素をページから排除するための条件で参照できます。表3-18に、PRINTER_FRIENDLY
を参照するためにサポートされている構文を示します。
LOGOUT_URL
はアプリケーション・レベルの属性であり、ログアウトURLの指定に使用されます。これは、ユーザーをログアウト・ページにナビゲートさせるか、またはオプションで直接ユーザーをログアウトさせるURLです。ログアウト・ナビゲーション・バー・エントリを作成するには、&LOGOUT_URL
の最後にピリオドを追加します(&LOGOUT_URL.
)。ページ・テンプレートをコーディングしている場合は、#LOGOUT_URL#
を使用します。表3-19に、LOGOUT_URL
を参照するためにサポートされている構文を示します。
PROXY SERVER
は、アプリケーション属性です。この属性は、ソースがURLであるリージョンによって使用される場合があります。次に、直接PL/SQLを参照する際の正しい構文を示します。この参照は、データベースからリモートWebサーバーにアクセスするためのPL/SQLを記述する場合に使用します(たとえば、データベースに付属するutl_http
パッケージを使用する場合)。
APEX_APPLICATION.G_PROXY_SERVER
PUBLIC_URL_PREFIX
は、アプリケーション・レベルの属性であり、ログイン・モードをパブリック表示に切り替えるURLを指定します。表3-20に、PUBLIC_URL_PREFIX
を参照するためにサポートされている構文を示します。
REQUEST
の値は、各アプリケーションのボタンによって、そのボタンの名前またはそのボタンに関連付けられているリクエスト値属性に設定されます。これによって、ユーザーがボタンをクリックしたときに、受入れプロセスでそのボタンの名前が参照されるようになります。f?p
構文では、REQUEST
は4つ目の引数を使用して設定できます。
ページをポストすると、受入れプロセスが起動されます。受入れプロセスは、計算、検証、プロセスおよびブランチで構成されています。REQUEST
の値は、受入れプロセスの各フェーズで使用可能です。アプリケーションが別のページにブランチされると、REQUEST
はNULLに設定されます。
REQUEST
の値は、ユーザーがクリックするボタンの名前か、またはユーザーが選択するタブの名前です。たとえば、名前がCHANGE
、ラベルが「変更の適用」というボタンがあるとします。ユーザーがこのボタンをクリックすると、REQUEST
の値がCHANGE
になります。
検証、プロセスおよびブランチには「対象ボタン」属性があります。この属性は、選択リストとして表示され、カレント・ページにあるボタン名を含みます。「対象ボタン」から選択した場合、ボタンのREQUEST
値を検証、プロセスまたはブランチに関連付けます。
ページの送信にボタンを使用する場合、REQUEST
値がページに渡されます。受入れプロセス・ロジックにより、「対象ボタン」属性を使用する各検証、プロセスおよびブランチが評価され、コンポーネントを実行(起動)するかどうかが決定されます。コンポーネントの1つが実行される場合、関連付けられたボタンをユーザーが実際にクリックしてページが送信されたとはみなさないでください。同じリクエスト値を使用する別のボタンがページを送信した可能性があります。同様に、ページのJavaScriptもページを送信してリクエスト値を渡します。
REQUEST
は、通常、条件を使用して参照されます。たとえば、ユーザーがレポート・ページ上の「実行」をクリックしたときにページ区切りをリセットする必要がある場合があります。ページ区切りは、送信時ページ・プロセスを作成してリセットできます。ページ・プロセスには、条件「リクエスト=式1」を使用して条件を付けることができます。
送信時ページ・プロセスに条件を設定するには、次のステップを実行します。
「条件」で、条件タイプ「リクエスト=式1」を選択します。
式1で「実行」を実行します。
REQUEST
は、f?p
構文を使用してページに移動するときの表示プロセスにも使用できます。次に例を示します。
f?p=100:1:&APP_SESSION.:GO
f?p
構文の4つ目の引数がREQUEST
です。この例では、カレント・セッションのアプリケーション100のページ1に移動し、REQUEST
の値がGO
に設定されます。すべてのプロセスまたはリージョンでは、表示プロセスを使用してREQUEST
の値を参照できます。
次に、PL/SQLを使用した同様の例を示します。
IF V ('REQUEST') = 'GO' THEN htp.p('hello'); END IF;
htp.p('hello')
は、特定のテキスト文字列を出力するためのPL/SQL Webツールキット・パッケージへのコールであることに注意してください。
参照:
|
SQLERRM
は、アプリケーション・リージョン・エラー・メッセージでのみ使用可能なテンプレート置換です。次に、リージョン・テンプレート置換を参照する際の正しい構文を示します。
#SQLERRM#
SYSDATE_YYYYMMDD
は、データベース・サーバーの現在の日付にYYYYMMDD
書式マスクを適用して表示します。この値を、SYSDATE()
ファンクションを繰り返しコールするかわりに使用できます。次のリストに、SYSDATE_YYYYMMDD
を参照するためにサポートされている構文を示します。
バインド変数
:SYSDATE_YYYYMMDD
PL/SQL
V('SYSDATE_YYYYMMDD')
直接PL/SQL
APEX_APPLICATION.G_SYSDATE (DATE DATATYPE)
この置換文字列を使用して、作業領域内の複数のアプリケーションで共有されているアップロードされたイメージ、JavaScriptおよびカスケード・スタイルシートを参照します。表3-23に、WORKSPACE_IMAGES
を参照するためにサポートされている構文を示します。
表3-23 WORKSPACE_IMAGES構文
参照タイプ | 構文 |
---|---|
バインド変数 |
|
直接PL/SQL |
使用不可 |
PL/SQL |
|
置換文字列 |
|
テンプレート置換 |
|