Lightning Experience 用の Visualforce ページの開発

学習の目的

この単元を完了すると、次のことができるようになります。
  • Lightning Experience の開発環境の設定を完了する。
  • Lightning Experience で作成中の Visualforce ページを表示する 2 通りの方法について説明する。
  • Visualforce ページの作成中にプレビューすることと、そのページの正式なテストを行うことの違いを説明する。
  • Visualforce ページの正式なテストの実施時に、テストに含めるべき各要素を説明するテストマトリックスを作成する。

Lightning Experience 向けの Visualforce ページの作成

Lightning Experience 向けの Visualforce ページやアプリケーションを作成するプロセスは、いくつかの点で Salesforce Classic 向けの作成とかなり異なります。一方で、まったく同じ点もあります。主な違いは、作成中にページを表示およびテストする方法です。

この単元では、開発環境の設定について詳述し、続いてページを作成しながらテストする「正しい」方法について詳しく解説します。嬉しいことに、Lightning Experience 向けの作成で使用する必要のあるプロセスは、Salesforce モバイルページの作成に使用するプロセスと同じです。

エディタの設定

まず初めに設定しておきたいのが、コードの記述に使用する編集ツールです。Lightning Experience、Salesforce Classic、Salesforce アプリケーションのどのページを作成する場合でも、開発者コンソール、Visual Studio Code 向け Salesforce 拡張機能、昔ながらの設定エディタのどれを使用する場合でも、設定のプロセスに変わりはありません。

推奨の Visualforce 編集ツールをすでに手にしている場合は、ここで何もする必要はありません。Visualforce のマークアップの記述や保存もまったく同じです。開発者コンソールには独自のユーザインターフェースがあり、Lightning Experience と Salesforce Classic との間に違いはありません。[設定] のエディタにも変更はなく、すべてのユーザインターフェースコンテキストで Salesforce Classic ユーザインターフェースが維持されています。そしてもちろん、Visual Studio Code 向け Salesforce 拡張機能や利用可能なさまざまなサードパーティ製ツールのいずれかなど、ネイティブツールを使用している場合も、それぞれ独自のユーザインターフェースがあります。

この例外の 1 つが、Visualforce 開発モードフッターのエディタです。ユーザ設定で開発モードを有効にし、Salesforce Classic を使用している場合は、ご推察どおり、開発モードフッターを使用した Visualforce ページの表示および編集に変更はありません。Lightning Experience に切り替えてから、従来の https://yourInstance.salesforce.com/apex/PageName という URL パターンを使用してページにアクセスしたときに、Salesforce Classic に舞い戻ったことに気付いて多少驚くことがあるかもしれません。

これは予想される動作で、Visualforce ページの表示およびテストのセクションで詳しく説明します。ここでは、Visualforce の開発モードは Salesforce Classic でしか使用できないことを覚えておいてください。

開発中の Visualforce ページの表示

作成中の Visualforce ページを表示することは一般的なタスクです。そして、正式な「テスト」を行っているとき以外にも、作成したばかりの機能を操作して、適切な動作につながるものであることを確認することが望まれます。https://yourInstance.salesforce.com/apex/PageName という URL パターンを使用してページにアクセスすれば、新しい機能を頻繁に確認できます。この方法は Salesforce Classic でのページの確認には従来どおり機能しますが、Lightning Experience の動作の確認には機能しません。

URL に直接アクセスしてページを表示する場合は、常に Salesforce Classic に表示されます。つまり、ユーザインターフェース設定に関係なく、「従来」の Visualforce コンテナに表示されます。Lightning Experience 固有の動作を含む Visualforce ページを作成した場合、通常の URL に直接アクセスしただけでは動作を確認できません。

高度な操作

この原因はバックグランド動作にあり、ごく簡単なことです。Lightning Experience でページを表示するためには、Lightning Experience コンテナアプリケーションにアクセスする必要があります。つまり /lightning にアクセスしなければなりません。このアプリケーションにアクセスしているときは、/apex/PageName にはアクセスできません。この 2 つは異なる URL で、重複することがありません。

では開発者はどうすればよいのかというと、Lightning Experience アプリケーション内からページを表示して、ページが Lightning Experience コンテナ内で実行されるようにします。つまり、Lightning Experience のページに移動する必要があるわけですが、この移動にはさまざまな方法があります。

特定の Visualforce ページに移動する手っ取り早い方法は、そのページのタブを作成して、アプリケーションランチャーの [すべての項目] セクションからそのタブに移動することです。より長期的な方法は、「開発中」アプリケーションを作成して、作業時に Visualforce タブを追加した後、本番環境にロールアウトするときにそのタブを移動または削除することです。この処理を行うコントロールの配置が若干変わっているため、簡単に説明しておきます。

  1. [設定] から、[クイック検索] ボックスに「アプリケーション」と入力し、[アプリケーションマネージャ] を選択します。[Lightning Experience アプリケーションマネージャ] の [設定] ページが表示されます。
  2. [新規 Lightning アプリケーション] をクリックしてから、作成中のページのカスタムアプリケーションを作成します。アプリケーションへのアクセスを、システム管理者または組織の開発者向けに作成したプロファイルに制限することを検討します。限られたプロファイルにアプリケーションを割り当ててアクセスを制御する ユーザインターフェースの最終的な位置にページが配置されるまで、ユーザにページを表示する必要はありません。
  3. [設定] から、[クイック検索] ボックスに「アプリケーションメニュー」と入力し、[アプリケーションメニュー] を選択します。[アプリケーションメニュー] の [設定] ページが表示されます。
  4. 「開発中」アプリケーションが [アプリケーションランチャーで表示] に設定されていることを確認します。この作業を行っている間に、項目の配置を変えたい、あるいは使用しないアプリケーションを非表示にしたいなどと思うことがあります。アプリケーションランチャーのアプリケーションの表示および順序
  5. [設定] から、[クイック検索] ボックスに「タブ」と入力し、[タブ] を選択します。[カスタムタブ] の [設定] ページが表示されます。
  6. [Visualforce タブ] セクションの [新規] をクリックして、現在作成中のページのカスタムタブを作成します。このタブは開発ユーザプロファイルのみに表示し、「開発中」アプリケーションのみに追加します。開発タブが開発者のみに表示されるようにする 「開発中」アプリケーションにタブを追加
  7. 「開発中」アプリケーションに追加するページごとに上記のステップを繰り返します。将来新しいページを追加する場合も、このステップを実行するだけです。
上記は作業中のページを表示する簡単な方法ですが、何よりも簡単な方法はただ URL にページ名を入力することです。Lightning Experience でページをテストする場合は、同じくらい手間のかからない方法として、JavaScript コンソールに次のコードを入力することもできます。
$A.get("e.force:navigateToURL").setParams(
    {"url": "/apex/pageName"}).fire();
この JavaScript は Lightning Experience の navigateToURL イベントを実行するもので、従来の /apex/PageName URL に入力することと同じです。この URL パターンをコードで確認することもできます。
メモ

メモ

現時点では、Lightning Experience で作業している場合に限りこの方法を使用できます。Salesforce Classic で作業している場合は、JavaScript コードを実行しても失敗します。

もう少し簡便な方法を望む場合は、ブラウザのメニューまたはツールバーに次のブックマークレットを追加します 。(読みやすくするためにこのコードはラップされています)。
javascript:(function(){
    var pageName = prompt('Visualforce page name:');
    $A.get("e.force:navigateToURL").setParams(
        {"url": "/apex/" + pageName}).fire();})();
このブックマークレットによってページ名を入力する画面が表示され、その後直接そのページに移動するイベントが実行されます。とても便利な方法です。

作業しているページに移動したら、単にブラウザの再読み込みコマンドを使用して、変更を行うたびにページが更新されるようにすることができます。

複数の環境の Visualforce ページの確認

Lightning Experience、Salesforce Classic、および Salesforce アプリケーションで使用するページを作成している場合、対象のすべての環境でページを確認できるに越したことはありません。複数の環境で確認するには、複数のブラウザおよび複数のデバイスでページを開く必要があります。

さまざまな Salesforce ユーザインターフェースコンテキストやフォーム要素で使用する予定の Visualforce ページを開発しながら確認する場合は注意が必要です。プロファイルメニューの環境セレクタを使用すれば、Salesforce Classic と Lightning Experience を切り替えることができますが、この方法はじきに旧弊なものになるでしょう。同様に、ブラウザのユーザエージェント設定を操作して Salesforce モバイル環境をシミュレートすることも可能ですが、この方法はさらに厄介です。

代わりに、複数のデバイス、あるいは複数のブラウザを使用してページを表示することを検討します。そして、1 人以上のテストユーザも追加してアクセスできるようにします。以下に、開発環境の設定例を示します。

メインの開発環境: この環境では、[設定] から、カスタムオブジェクトや項目の追加などの組織への変更を行います。また、開発者コンソールを使用する場合は、実際のコードを記述することも考えられます。
  • ブラウザ: Chrome
  • ユーザ: 開発ユーザ
  • ユーザインターフェース設定: Salesforce Classic
この環境では Salesforce Classic でのページの設計や動作を確認します。Lightning Experience の確認環境: この環境では、Lightning Experience でのページの設計や動作を確認します。
  • ブラウザ: Safari または Firefox
  • ユーザ: テストユーザ
  • ユーザインターフェース設定: Lightning Experience
Salesforce モバイルのレビュー環境: この環境では、Salesforce アプリケーションでのページの設計や動作を確認します。
  • デバイス: iOS または Android のスマートフォンやタブレット
  • ブラウザ: Salesforce アプリケーション
  • ユーザ: テストユーザ
  • ユーザインターフェース設定: Lightning Experience
メモ

メモ

上記の設定は一例にすぎず、Salesforce Classic と Lightning Experience のどちらの場合も各自の環境の最新のブラウザやモバイルデバイスを使用できます。この設定のポイントは、2 つの異なるブラウザを使用して一度に Salesforce Classic と Lightning Experience の両方にアクセスできるようにすることと、Salesforce アプリケーションを実際のデバイスでテストすることです。

かなり面倒だと思えるかもしれません。実際、特にコードの記述を始めようと意気込んでいるときなどは、こうした諸々の初期設定は煩わしいものです。そんなときには、次の 2 つのことを思い出してください。1 つは、いったん設定してしまえばそれで済むということです。そしてもう 1 つは、このワークスペースが最適な開発環境となるだけでなく、ページの正式なテストに必要な環境にもなるということです。ページを本番環境にリリースするためには、必ずや正式なテストをする必要がありますから。

Visualforce ページのテスト

Visualforce ページを本番組織にリリースする前にテストすることは、とても重要な開発タスクです。組織が Lightning Experience を採用した場合は、ページをテストするプロセスが一層複雑になります。

ページを作成中に略式のテストを行うために設定する必要のある環境については、すでに説明しました。ページやアプリケーションの正式なテストでもこれらの環境が必要になります。ここで同じ説明は繰り返しませんが、これらの環境が必要な理由について簡単に説明します。

Lightning Experience と Salesforce Classic の両方でページをテストする必要のあることは明らかですが、このテストを同一のユーザが同一のブラウザで実施できないのはなぜでしょうか。実際には実施可能ですし、実施すべきです。ユーザは異なるユーザインターフェースに自在に切り替えることができるのですから、ユーザが切り替えたときにページが機能することを確認すべきです。

他方、ページをやや隔離した状態で体系的にテストしたいと思うことがあります。こうした方法ではページの基本的な機能を、各自のコード、当社のコード、ブラウザのコード、デバイスのコードなど他のコードの影響を極力切り離してテストできます。

デスクトップやモバイルブラウザは、たとえ同じベンダの製品でも動作が異なります。まったく違うこともあります。サポートする予定のあらゆるデバイスおよびあらゆるブラウザでテストしない限り、正式なテストを厳密に行うことにはなりません。

個別のページや、同質のデバイスの基本的なアプリケーションを開発している場合であれば、各要素のマトリックスがシンプルなものになると思われます。他方、より野心的なプロジェクトで、広範な可能性をサポートする必要のある機能を開発している場合は、テストプランで次のテスト対象を網羅する必要があります。

  • サポート対象の各種デバイス。
  • サポート対象の各種オペレーティングシステム。
  • サポート対象の各種ブラウザ (ブラウザを埋め込む Salesforce アプリケーションを含む)。
  • サポート対象の各種ユーザインターフェースコンテキスト (Lightning Experience、Salesforce Classic、Salesforce アプリケーション)。

幸いにも、これらの要素の中には、失敗するときはまとめて失敗するものがあり、必ずしもすべての組み合わせをテストしなければならないわけではありません。たとえば、Apple モバイルデバイスの大半は iOS の最新バージョンに更新されているものと考えられます。つまり、デバイスとオペレーティングシステムとブラウザが効率的に 1 つにまとめられています。したがってテストプランでは、最新の iOS と Salesforce アプリケーションに更新された 1 台の iPhone と 1 台の iPad をテストすれば済むものと思われます。

テストに関してもう 1 点述べておきたいことがあります。開発環境とテスト環境を近づけることを強く勧めるもう 1 つの理由は、開発プロセスの早い段階からテスト、それも完全なテストが行えるためです。セカンダリデバイスでのテストは往々にしてプロジェクトの終盤まで後回しにされることが判明しています。終盤になって問題が見つかれば、後戻りせざるを得ません。

早期に、頻繁に、すべてをテストします。

無料で学習を続けましょう!
続けるにはアカウントにサインアップしてください。
サインアップすると次のような機能が利用できるようになります。
  • 各自のキャリア目標に合わせてパーソナライズされたおすすめが表示される
  • ハンズオン Challenge やテストでスキルを練習できる
  • 進捗状況を追跡して上司と共有できる
  • メンターやキャリアチャンスと繋がることができる