Lightning Experience 用の Visualforce ページの開発

この単元では、開発環境の設定について詳述し、続いてページを作成しながらテストする「正しい」方法について詳しく解説します。嬉しいことに、Lightning Experience 向けの作成で使用する必要のあるプロセスは、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 でしか使用できないことを覚えておいてください。

URL に直接アクセスしてページを表示する場合は、常に Salesforce Classic に表示されます。つまり、ユーザインターフェース設定に関係なく、「従来」の Visualforce コンテナに表示されます。Lightning Experience 固有の動作を含む Visualforce ページを作成した場合、通常の 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();})();

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

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

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

• ブラウザ: Chrome
• ユーザ: 開発ユーザ
• ユーザインターフェース設定: Salesforce Classic

• ブラウザ: Safari または Firefox
• ユーザ: テストユーザ
• ユーザインターフェース設定: Lightning Experience

• デバイス: iOS または Android のスマートフォンやタブレット
• ブラウザ: Salesforce アプリケーション
• ユーザ: テストユーザ
• ユーザインターフェース設定: Lightning Experience

メモ

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

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

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

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

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

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

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

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

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

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

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