2.9 New Application Types
To promote consistency and simplify shared component reuse, three new types of applications are now available:
- Theme - Contains a theme definition that defines the visual style of an application through theme assets such as styles, templates, and template components.
- Library - Contains reusable shared components such as authentication schemes and lists of values (LOVs) that can be subscribed to by standard applications.
- Boilerplate - Provides seeded shared component subscriptions and pre-built pages designed to accelerate the creation of new applications.
これまでのAPEXのアプリケーションでもアプリケーションが異なる共有コンポーネントを、サブスクライブすることにより参照することができました。APEX 26.1から、サブスクライブされる共有コンポーネントを保持するためだけのアプリケーション・タイプとして、テーマとライブラリが設定されています。
アプリケーション・タイプがテーマであるアプリケーションは、スタイル、テンプレートおよびテンプレート・コンポーネントを保持します。
アプリケーション・タイプがライブラリであるアプリケーションは、認証スキーム、LOVおよびリストなどを保持します。
アプリケーションの見た目に関するテーマは、多くの場合、すべてのアプリケーションに適用することが多いと思います。そのため、アプリケーション・タイプがテーマのアプリケーションはAPEXワークスペースにひとつまたは少数作成し、それをその他のアプリケーションから参照する使い方になるでしょう。
認証スキーム、LOVやリストなどは、例えば顧客管理や販売管理といったアプリケーションのグループ単位で共有するものが多く、アプリケーション・タイプをライブラリとして、テーマよりも細かい単位で分けて保持させます。
ボイラープレートは、テーマやライブラリとは異なり、共有コンポーネントを保持するためのアプリケーション・タイプではありません。あらかじめテーマやライブラリのサブスクライブやアプリケーションへの適用を行なった後に、アプリケーション・タイプをボイラープレートに変更し、新規に作成するアプリケーションの雛形とするものです。アプリケーション・タイプがボイラープレートのアプリケーションがAPEXワークスペースに存在すると、アプリケーションの作成時に雛形のアプリケーションとして、それらのボイラープレートを選択することができます。
企業向けにカスタマイズしたテーマ・スタイルが適用され、必要な共有コンポーネントがサブスクライブ済みの状態から、アプリケーション開発を始めることができます。
アプリケーション・タイプがテーマ、ライブラリ、ボイラープレートのアプリケーションは、としては、アプリケーションとしては実行できません。
今から5年以上前になりますが、共有コンポーネントのサブスクライブを活用し、ひとつの大きなAPEXアプケーションを複数のアプリケーションに分割しする手順を解説しています。
新しいアプリケーション・タイプの導入は、アプリケーションの分割を、よりシステムとして定義された方法で実施できるようにします。
APEXのアプリケーションはデプロイメントの単位がアプリケーションになっています。例えば、100ページある1つのAPEXアプリケーションを10人で共同開発するよりも、10ページある10のアプリケーションを、それぞれ10人で開発する方が、それぞれのアプリケーションを個別にデプロイ(エクスポートやインポートおよび動作確認など)できるため、開発効率が高くなります。
これ以降は、5年前の記事に書いた作業を、APEX 26.1のアプリケーション・タイプを使う形で実施し直してみます。
- 例題アプリケーションの作成
- アプリケーションの分割
- セッションの共有
- ホーム・ページ、ログイン・ページの共有
- ナビゲーションの更新
- テーマのサブスクリプション
- 共有コンポーネントのリフレッシュ
- ボイラープレート
例題アプリケーションの作成
SQLワークショップのサンプル・データセットより、プロジェクト・データをインストールし、それを元にアプリケーションを作成します。
SQLワークショップのユーティリティに含まれるサンプル・データセットを開きます。
プロジェクト・データのインストールをクリックします。
データセットの説明が表示されます。次へ進みます。
ロード結果が表示されます。そこからアプリケーションの作成を起動します。
言語を日本語(ja)に変更してアプリケーションの作成を行います。
以上で例題として使用するアプリケーションが完成しました。
アプリケーションの分割
作成されたアプリケーションをコピーして、以下の3つのアプリケーションを準備します。
ライブラリ用途 - Projects:認証スキーム、メニュー、LOVを含むライブラリ・アプリケーション。アプリケーション別名はprojectsとします。このアプリケーションはすでに作成済みです。アプリケーション - Projects - Home:ページとしてHome、Dashboard、Statuses、Project Status、ログイン・ページ、管理を含む標準アプリケーション。アプリケーション別名はprojects-homeとします。
アプリケーション - Projects - Main:ページProjects、Milestones、Tasks、Project Task、Task Calendarを含む標準アプリケーション。アプリケーション別名はprojects-mainとします。
グローバール・ページはProjects - Home、Projects - Mainの双方のアプリケーションに含めます。
新規アプリケーション名はProjects - Homeとします。パブリック・レポートは作成されていないので、パブリック・レポートのコピーはオンでもオフでも結果は同じです。
次へ進みます。
確認画面からアプリケーションのコピーを実行します。
アプリケーションProjectsのコピーがProjects - Homeとして作成されます。
作成されたアプリケーションの別名をPROJECTS-HOMEに変更します。5年前とは異なり、簡易URLは必ずオンにします。
アプリケーションProjects - Homeからは、ページ3, 4, 5, 6, 7を削除します。
ページ・デザイナにて、ひとつひとつページを開いて、削除していきます。
ページ3、4、5、6、7ではカスケード削除は、いいえ - 対応するリスト・エントリを削除しないを選択し、ナビゲーション・メニューのリストからエントリが削除されないようにします。フォームのように、ナビゲーション・メニューに紐づいていないページでは、カスケード削除は表示されません。
ページを完全に削除を実行します。
アプリケーションProjects - Homeに、グローバル・ページ、Home、Dashboard、Statuses、Project Status、ログイン・ページ、管理が残ります。
ページの別名はナビゲーション・メニューのターゲット指定に使用します。それぞれのページに割り当てられている別名を覚えておきます。(ページ別名の管理については日本語の別名を英数字に変更すべきですが、今回はページ番号の10000をターゲット指定に使用します)。
アプリケーションProjects - Homeについては一旦作業は完了です。
アプリケーションProjects - Mainからは、ページ1, 2, 8, 9および9999と10000を削除します。
アプリケーションProjects - Mainに、グローバル・ページ、Projects、Milestones、Tasks、Project Taskが残ります。
ページの別名はナビゲーション・メニューのターゲット指定に使用します。それぞれのページに割り当てられている別名を覚えておきます。
アプリケーション・ビルダーにてアプリケーションProjectsを開き、アプリケーション・タイプをライブラリに変更します。
アプリケーション・タイプがライブラリまたはテーマであるアプリケーションは、標準ページを含むことができません。そのため、エラーが発生し、アプリケーション・タイプを切り替えることができません。
アプリケーションProjectsに含まれる標準ページをすべて削除します。
アプリケーションProjectsからすべてのページが削除されています。
アプリケーションProjectsのアプリケーション・タイプをライブラリに変更します。
変更の適用を実行します。
アプリケーションProjectsのアプリケーション・タイプがライブラリに変更されました。
以上でアプリケーションの分割は完了です。次から、分割したアプリケーションを一体で動作するように設定を行なっていきます。
セッションの共有
ライブラリ・アプリケーションであるProjectsを開き、共有コンポーネントの認証スキームを開きます。
認証スキームのOracle APEXアカウントを開き、セッション共有の設定を変更します。
タイプをカスタムに変更し、Cookie名は任意の値(ここではORA_WWV_APP_PROJECTSとしています)に設定します。それ以外はOracle APEXをホストしているサーバーの環境によって決まる値ですので、ご自身の環境に合った値を設定してください。
- タイプ: カスタム
- Cookie名: ORA_WWV_APP_PROJECTS
- Cookieパス: 空白
- Cookieドメイン: 空白
- セキュア: OFF
アプリケーションProjects - Homeを開き、共有コンポーネントの認証スキームから、Oracle APEXアカウントを開きます。
サブスクリプションのサブスクライブ元として、ライブラリ・アプリケーションであるProjects(以下の例ではアプリケーションIDが109)が持つ認証スキームである109: Oracle APEXアカウントを選択します。
変更の適用を実行します。
現行の認証スキームの設定が、サブスクライブした認証スキームの設定に上書きされる旨、警告されます。
サブスクライブをクリックします。
認証スキームの一覧画面に戻ります。再度、Oracle APEXアカウントを開きます。
アプリケーションProjectsの認証スキームであるOracle APEXアカウントがサブスクライブされていることが確認できます。
アプリケーションProjects - Mainについても同様に、認証スキームOracle APEXアカウントを、ライブラリ・アプリケーションProjectsの認証スキームであるOracle APEXアカウントをサブスクライブするように設定します。
アプリケーションProjects - HomeとProjects - Mainで、同じ設定(特にクッキー名)の認証スキームをサブスクライブすることにより、アプリケーション間でセッションが共有されます。
ホーム・ページ、ログイン・ページの共有
今回はアプリケーションProjects - Homeに、ホーム・ページとログイン・ページを残しています。アプリケーションProjects - Mainは、ホーム・ページとログイン・ページとしてProjects - Homeのものを使うようにします。
アプリケーションProjects - Mainのアプリケーション定義のユーザー・インターフェースを開き、属性のホームURLとログインURLを変更します。
- ホームURL: f?p=projects-home:home:&APP_SESSION.::&DEBUG.:::
- ログインURL: f?p=projects-home:LOGIN:&APP_SESSION.::&DEBUG.:::
&APP_ID.置換文字列は自分自身のアプリケーションIDを意味するので、これをホーム・ページやログイン・ページを持つアプリケーションの別名であるprojects-homeへ置き換えます。また、ホームURLのページが1として数値で設定されていたので、別名のhomeに置き換えています。アプリケーションIDやページIDとして指定する部分には、できるだけ数値は使わない方がアプリケーションのメンテナンスが容易になります。
こちらについては、アプリケーションProjects - Mainだけの変更になります。アプリケーションに認証が必要なアクセスがあった場合、および、ホームページに移動する場合は、アプリケーションProjects - Homeへ遷移するようになります。
ナビゲーションの更新
ページ1、2、10000はアプリケーションProjects - Home、ページ3, 4, 5, 7はアプリケーションProjects - Mainをアクセスするよう、ナビゲーション・メニューを更新します。
ライブラリ・アプリケーションProjectsの共有コンポーネントのリストを開きます。この中のナビゲーション・メニューとページ・ナビゲーションを変更します。
他にも変更すべきリストはありますが、今回の例題の確認には影響がないため、そのままにします。
ナビゲーション・メニューを開いて、グリッド編集をクリックします。
分割されたアプリケーションを指すエントリのターゲットに、アプリケーションの別名を指定します。
- Home: f?p=projects-home:home:&APP_SESSION.::&DEBUG.:::
- Dashboard: f?p=projects-home:dashboard:&APP_SESSION.::&DEBUG.:::
- Projects: f?p=projects-main:projects:&APP_SESSION.::&DEBUG.:::
- Milestones: f?p=projects-main:milestones:&APP_SESSION.::&DEBUG.:::
- Tasks: f?p=projects-main:tasks:&APP_SESSION.::&DEBUG.:::
- Tasks Calendar: f?p=projects-main:tasks-calendar:&APP_SESSION.::&DEBUG.:::
- 管理: f?p=projects-home:10000:&APP_SESSION.::&DEBUG.:::
ターゲットが適切に更新されていることを確認し、変更の適用を実行します。
ページ・ナビゲーションは、Homeと管理は含みません。
タスクからテーマのコピーを実行します。
アプリケーションにたいして簡易URLを設定していても、ナビゲーションに指定するURLについてはf?p=形式のURLを使用できます。簡易URLの形式で指定するにはワークスペース名を含める必要があるなど、ナビゲーションの宛先URLとしては使いにくいのでf?p=形式で指定できるのは助かります。
ライブラリ・アプリケーションProjectsで更新したリストであるナビゲーション・メニューおよびページ・ナビゲーションを、アプリケーションProjects - HomeとProjects - Mainからサブスクライブします。
それぞれのアプリケーションで、共有コンポーネントのリストのナビゲーション・メニューを開きます。
サブスクリプションのサブスクライブ元として109: ナビゲーション・メニューを選択し、変更の適用を実行します。109はライブラリ・アプリケーションProjectsのアプリケーションIDです。
リスト・エントリのターゲットが更新されるので、確認します。
同様に、共有コンポーネントのリストのページ・ナビゲーションを開き、109: ページ・ナビゲーションをサブスクライブします。
アプリケーションProjects - Mainについても上記と同様の作業を行ない、ナビゲーション・メニューとページ・ナビゲーションを、ライブラリ・アプリケーションProjectsからサブスクライブします。
ページの遷移にまつわる設定は以上で完了です。アプリケーションを実行して動作を確認してみます。
アプリケーションProjects - HomeとProjects - Mainのどちらを実行しても、Projects - Homeのログイン・ページが開きます。
ナビゲーション・メニューやホーム・ページのナビゲーションをクリックして、アプリケーション自体も遷移すること、アクセスするアプリケーションが変わっても再認証が求められないことを確認します。
テーマのサブスクリプション
テーマのサブスクリプションの例として、テーマ・スタイルを共有してみます。アプリケーションは何でも構いませんが、壊しても問題ないアプリケーションで作業します。
最初にカスタマイズするテーマを、標準のUniversal Themeのコピーとして作成します。
共有コンポーネントのテーマを開きます。
次へ進みます。
テーマのコピーを実行します。
テーマIDが1042で、Universal Themeのコピーが作成されます。
テーマを切り替えます。コピーなので、テーマを切り替えてもアプリケーションの見た目は変わりません。
内容は同じテーマなので、互換性の確認のテンプレートからと、テンプレートにの設定は同じになります。
次へ進みます。
テーマの切替えを実行します。
コピーとして作成したテーマUniversal Theme - 1042が、カレントのテーマに切り替わります。
APEXアプリケーションを実行します。
テーマ・ローラーを使用して、既存のテーマ・スタイルをカスタマイズして保存します。
ヘッダーを淡(英語でLight)、ナビゲーションも淡に変更し、新しいテーマ・スタイルとして別名保存します。
新しいスタイル名をIris Lightとし、保存します。
作成されたテーマ・スタイルを確認します。
共有コンポーネントのテーマを開きます。
回避策として、追加したテーマ・スタイルのIris Lightを手作業でコピーします。テーマ・スタイルIris Lightの属性値などをメモします。
Universal Theme - 1042を開き、スタイル・セクションからIris Lightを開きます。
設定のパブリック、アクセシビリティのテスト済、ファイルURLやテーマ・ローラー属性の読取り専用、入力パラメータ・ファイルURL、出力CSSファイルURL、テーマ・ローラーJSON構成を、どこかに記録しておきます。
出力CSSファイルURLとして設定されているファイルは、データベースに保存されています。
テーマの編集画面に戻り、ファイル・セクションを開きます。
出力CSSファイルが見つかるので、これをダウンロードします。
以上で、別のアプリケーションにテーマIris Lightを作成するために必要な情報が取得できました。
新規にアプリケーションを作成して、アプリケーション・タイプをテーマに変更します。
空のアプリケーションを作成します。名前はMy Themesとします。
アプリケーションMy Themesが作成されます。デフォルトで作成されるページ、グローバル・ページ、ホーム、ログイン・ページは削除します。
共有コンポーネントのテーマを開きます。
テーマのコピーを実行し、テーマIDが1042のテーマを作成します。テーマをコピーする手順はすでに提示済みなので省略します。
コピーとして作成したテーマUniversal Theme - 1042を開き、テーマ・スタイルとしてIris Lightを追加します。
スタイル・セクションのスタイルの追加をクリックします。
テーマ・スタイルの名前はIris Lightです。先ほど記録した設定値を戻し、テーマ・スタイルを作成します。
テーマ・スタイルとしてIris Lightが作成されます。
現在のテーマ・スタイルをIris Lightに変更したのち、ファイル・セクションに移ります。
ファイルの作成をクリックします。
アップロードしたファイルが、データベースから参照されるファイルとして保存されます。
参照の値は、テーマ・スタイルIris Lightの出力CSSファイルURLに一致します。
以上で、テーマ・スタイルIris Lightを含むテーマが準備できました。
アプリケーション定義のアプリケーション・タイプを、テーマに変更します。
アプリケーションProjects - HomeとProjects - Mainのテーマ・スタイルをIris Lightに変更します。
共有コンポーネントのテーマを開き、作成をクリックします。
別のテーマからのコピーとしてを選択し、次へ進みます。
アプリケーションに、先ほどアプリケーション・タイプをテーマに変更したアプリケーションを選択します。
次のテーマからコピーにテーマIDが1042の1042. Universal Themeを選択します。
このテーマIDにコピーに1042を指定します。テーマのサブスクライブはオンです。
次へ進みます。
テーマのコピーを実行します。
テーマ・スタイルIris Lightを含むテーマが作成されます。
テーマの切替えを行い、カレント・テーマに変更します。
次のテーマに切替えに1042. Universal Themeを選択します。
次へ進みます。
互換性の確認はそのまま変更せず、次へ進みます。
テーマの切替えを実行します。
カレントのテーマが切り替わります。
アプリケーションProjects - HomeとProjects - Mainで同様の作業を繰り返し、両方のアプリケーションのテーマ・スタイルをIris Lightに切り替えます。
テーマおよびテーマ・スタイル変更後にアプリケーションを実行します。
アプリケーションProjects - Homeのテーマ・スタイルがIris Lightに変わっていることが確認できます。
アプリケーションProjects - Mainについても、テーマ・スタイルがIris Lightに変わっていることが確認できます。
アプリケーション・タイプをテーマにすると、アプリケーションとして実行できなかったり、現状はテーマのインポートでエラーが発生したりするので、テーマ・スタイルなどを頻繁に変更する状況では、アプリケーション・タイプをテーマにせず標準のままでテーマのサブスクライブ元にした方が、開発はしやすいように思います。
以上でアプリケーションの分割と、分割したアプリケーションの共通部分を、それぞれアプリケーション・タイプがライブラリおよびテーマのアプリケーションからサブスクライブするように、アプリケーションを構成することができました。
共有コンポーネントのリフレッシュ
サブスクライブ元のコンポーネントが変更された場合は、サブスクリプション・ステータスがリフレッシュが必要に変わります。
例えば、アプリケーションProjectsのナビゲーション・メニューが変更されると、それをサブスクライブしているアプリケーションProjects - HomeおよびProjects - Mainのナビゲーション・メニューのサブスクリプション・ステータスがリフレッシュが必要に変わります。
リフレッシュが必要な場合、それぞれのコンポーネントのサブスクリプションのセクションに、リフレッシュを実行するボタンが現れます。
リフレッシュを実行すると、サブスクライブ元の変更が反映されます。
逆にいうと、リフレッシュを実行するまでは、サブスクライブ元のコンポーネントが変更されてもアプリケーションには反映されません。
ボイラー・プレート
アプリケーション・タイプがボイラー・プレートのアプリケーションを作成します。
アプリケーションProjects - Homeのコピーを作成します。
アプリケーションの名前はProjects - Boilerplateとします。パブリック・レポートのコピーはオフにします。
アプリケーションのコピーを実行します。
本来は重複するページは削除すべきですが、ボイラープレートからどのようにアプリケーションが作成されるかを確認するため、すべてのページをそのまま残します。
新規にアプリケーションを作成します。
ボイラープレートからのアプリケーション作成を選択します。
ワークスペースに作成されているボイラープレートが一覧されます。
先ほど作成したProjects - Boilerplateを選択します。
アプリケーション名、アプリケーションIDおよび解析対象スキーマなどを設定し、アプリケーションの作成を実行します。
新規にアプリケーションが作成されます。
このアプリケーションはボイラープレートのコピーなので、アプリケーションの開発に必要な共有コンポーネントやテーマなどが、あらかじめ含まれています。
今回の記事は以上になります。
Oracle APEXのアプリケーション作成の参考になれば幸いです。
追記:
今回のようにサブスクライブ元となるアプリケーションは、マスター・アプリケーションになります。これらのアプリケーションに含まれるコンポーネントをサブスクライブしているアプリケーションをAPEXlang形式でエクスポートすると、以下のようにアプリケーションIDが参照に含まれます。
list ナビゲーション-メニュー (
name: ナビゲーション・メニュー
subscription {
master: @/109/ナビゲーション-メニュー
}
環境の違いなどでマスター・アプリケーションのアプリケーションIDが変わる場合、アプリケーションのインポートができません。そのための対応方法が、APEX 26.1のリリース・ノートの以下のセクションに紹介されています。
10.1 Known Issues for Importing APEXlang Applications in App Builder
エクスポートしたファイルに含まれるdeployments/default.jsonに、マスター・アプリケーションへのマッピングを定義して対応します。
完































































































