タイプが選択リストまたはポップアップLOVのページ・アイテムにたいして、カスケードLOVのプロパティを指定することにより、リストされる一覧を、親となる別の選択リストやページ・アイテムの値にしたがって変更することができます。
カスケードLOVのテストに使用した表とテストデータは、以下のクイックSQLのモデルから生成しています。
# prefix: clov
# language: ja
# genpk: false
projects /insert 3
id num /nn
name
dept /insert 9
id num /nn
name
emp /insert 27
id num /nn
project_id num /nn /values 1,2,3
dept_id num /nn /values 1,2,3,4,5,6,7,8,9
name
プロジェクトの表CLOV_PROJECTSと担当部署の表CLOV_DEPTがあり、担当職員の表CLOV_EMPはプロジェクトと担当部署の双方を参照しています。カスケードLOVのテストに使用できるデータを生成するために参照制約の定義は行っていません。通常は外部キー参照の制約は付加します。
確認に使用したアプリケーションのエクスポートをこちらに置きました。クイックSQLで表を作成した後、アプリケーションをインポートすると手元で動作確認も可能です。
https://github.com/ujnak/apexapps/blob/master/exports/cascading-lov-test.sql
プロジェクトと担当部署はタイプが選択リストである通常のページ・アイテムの設定になります。担当職員の選択リストにカスケードLOVの設定を行います。
LOVのSQL問合せに、条件句を含んだSELECT文を設定します。
select name d, id r from clov_emp where dept_id = :P1_DEPT and project_id = :P1_PROJECT
カスケードLOVの親アイテムとして、条件句に含まれるページ・アイテムP1_PROJECT、P1_DEPTの選択リストを設定します。これだけで親アイテムの値が変更されたときに、このページ・アイテムP1_EMPの内容がリフレッシュされます。
親が必要がONになっているので、P1_PROJECT、P1_DEPTのどちらかがNULLの場合は(値が選択されていない)、P1_EMPのリフレッシュを行いません。LOVのSQL問合せが、条件句に含まれているページ・アイテムがNULLであっても結果を返す場合は、親が必要をOFFにして、必ずリフレッシュを実施させます。
親アイテムに設定されたページ・アイテムは送信するアイテムに含める必要はありません。これらのページ・アイテムはそのままLOVのSQL問合せに送信されます。それ以外のページ・アイテム、例えば、テキスト・フィールドなどをLOVのSQL問合せに使用する際には、送信するアイテムに、そのページ・アイテムを指定します。
プロジェクトの選択リストをテキスト・フィールドに変更してみます。先ほどはページ番号が1でしたが、この例ではページ番号は2です。
この場合、ページ・アイテムP2_PROJECTは親アイテムの指定から外し、送信するアイテムとして指定します。
親アイテムとして設定されていないため、ページ・アイテムP2_PROJECTを変更しても自動的にはP2_EMPのリストはリフレッシュされません。そのため、動的アクションを設定します。
動的アクションが起動されるタイミングは、ページ・アイテムP2_PROJECTが変更されたときです。
実行されるアクションはアイテムP2_EMPのリフレッシュです。
基本的にカスケードLOVとなる選択リストのSQLにはページ・アイテムが含まれるはずなので、共有コンポーネントにすることはないでしょう。親アイテムは通常の選択リストなので、共有コンポーネントのLOVを使うことができます。
以上でページ・アイテムが選択リスト、またはポップアップLOVの場合に設定できる、カスケードLOVの設定についての説明は終了です。
Oracle APEXのアプリケーション開発の一助になれば幸いです。
完