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 タブを追加した後、本番環境にロールアウトするときにそのタブを移動または削除することです。この処理を行うコントロールの配置が若干換わっているため、簡単に説明しておきます。

[Setup (設定)] から、[Quick Find (クイック検索)] ボックスに Apps (アプリケーション) と入力し、[App Manager (アプリケーションマネージャー)] を選択します。[Lightning Experience App Manager (Lightning Experience アプリケーションマネージャー)] の [Setup (設定)] ページが表示されます。
[新規 Lightning アプリケーション] をクリックしてから、作成中のページのカスタムアプリケーションを作成します。アプリケーションへのアクセスを、システム管理者または組織の開発者向けに作成したプロファイルに制限することを検討します。ユーザーインターフェースの最終的な位置にページが配置されるまで、ユーザーにページを表示する必要はありません。
[設定] から、[クイック検索] ボックスに「アプリケーションメニュー」と入力し、[アプリケーションメニュー] を選択します。[App Menu (アプリケーションメニュー)] の [Setup (設定)] ページが表示されます。
「開発中」アプリケーションが [アプリケーションランチャーで表示] に設定されていることを確認します。この作業を行っている間に、項目の配置を変えたい、あるいは使用しないアプリケーションを非表示にしたいなどと思うことがあります。
[Setup (設定)] から、[Quick Find (クイック検索)] ボックスに Tabs (タブ) と入力し、[Tabs (タブ)] を選択します。[Custom Tabs (カスタムタブ)] の [Setup (設定)] ページが表示されます。
[Visualforce タブ] セクションの [New (新規)] をクリックして、現在作成中のページのカスタムタブを作成します。このタブは開発ユーザープロファイルのみに表示し、「開発中」アプリケーションのみに追加します。
「開発中」アプリケーションに追加するページごとに上記のステップを繰り返します。将来新しいページを追加する場合も、このステップを実行するだけです。

上記は作業中のページを表示する簡単な方法ですが、何よりも簡単な方法はただ URL にページ名を入力することです。Lightning Experience でページをテストする場合は、同じくらい手間のかからない方法として、JavaScript コンソールに次のコードを入力することもできます。

$A.get("e.force:navigateToURL").setParams(
    {"url": "/apex/pageName"}).fire();

この JavaScript は Lightning Experience の navigateToURL イベントを実行するもので、従来の /apex/PageNameURL に入力することと同じです。この 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 つの理由は、開発プロセスの早い段階からテスト、それも完全なテストが行えるためです。セカンダリデバイスでのテストは往々にしてプロジェクトの終盤まで後回しにされることが判明しています。終盤になって問題が見つかれば、後戻りせざるを得ません。

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

リソース

Trailhead: Visualforce ページの作成と編集
Visualforce 開発者ガイド

予想時間

トピック

ヘルプをお探しですか?

Salesforce Platform のリソース