機械翻訳について

ステップ13: インライン・フレームでのコンポーネントのレンダリング

今までのサンプルでは、ページ内でインラインでレンダリングされるローカル・コンポーネントを示していました。 インライン・フレームでのコンポーネントのレンダリングを選択することもできます。

たとえばコンポーネントによって、ページに対して、プロパティが変更されるたびにページを再作成する必要がある万能でない更新が実行される場合に、インライン・フレームでコンポーネントをレンダリングすることを選択できます。 また、リモート・コンポーネントは、必ずインライン・フレームでレンダリングされます。

この項内のサンプルは、ローカル・コンポーネントの作成時に「iframeにレンダリングするコンポーネントの作成」オプションを選択した場合に作成されるファイルから取得されています。 ただし、これらの一連のファイルを取得し、それらをリモート・コンポーネントに同様に適用するようリモート・サーバーでホストできます。

インライン・フレームと非インライン・フレームのコンポーネントの類似点

設定パネル

「設定」パネルは必ずページのインライン・フレームに配置されるため、「設定」パネルのコードは、コンポーネントでインライン・フレームが使用されるかどうかにかかわらず変更されません。 両方の使用事例で同じ「設定」パネル・コードを作成します。

サイトSDK API

SDK APIは、どちらの使用事例でも同じです。 トリガーの発生、アクションのリスニング、およびプロパティ値の取得と設定に同じコードを使用します。 特定のプロパティはどちらの場合も適用できない場合がありますが(たとえば、インライン・フレームを使用しないコンポーネントに対して"height"プロパティを設定できないなど)、APIは同じままです。 したがって、これら両方のタイプのコンポーネントの間でコードをコピーできます。また、このチュートリアルで説明するサンプル・コードは両方の事例で機能します。

インライン・フレームと非インライン・フレームのコンポーネントの相違点

ファイル構造と依存関係

ローカル・コンポーネントの作成時に「iframeにレンダリングするコンポーネントの作成」を選択すると、自分用に作成された次のファイルが表示されます。
<component name>
    assets
        css
            app-styles.css
        js
            jquery.mn.js
            knockout.mn.js
            sites.min.js
        render.html
        settings.html
    appinfo.json
    _folder_icon.jpg

これらのファイルは、ページ上のインライン・フレームでコンポーネントをすぐに実行できるよう、作成されます。 この構造と標準的なローカル・コンポーネントの構造の主な相違点は、次のとおりです。

  • JavaScript依存関係:

    • コンポーネントが実行されるよう、これらのファイルの完全なコピーを取得しています。 これらのファイルは、インライン・フレーム・コンポーネントのサンプルを実行するために必要となります。 要件に基づいて、このディレクトリのコンテンツを追加および削除できます。

    • コンポーネントのassetsディレクトリの下にあるすべてのものは、コンポーネントの公開時にパブリック・サイトにプッシュされるため、jsディレクトリ内のすべてがサイト・ビルダーと実行時の両方で使用可能になります。

    • ノート: これらのファイルは利便性のために作成します。 インライン・フレーム・コンポーネントごとにこれらのファイルの別個のバージョンを作成するのでなく、テーマまたは別のパブリック・ロケーションへのこれらのファイルの統合を検討する必要があります。

  • render.html:

    • これは、AMDモジュールである、標準コンポーネントのrender.jsファイルとは対照的に、完全なHTMLドキュメントです。

コンポーネントの高さの管理

インライン・フレーム使用時の問題の1つは、インライン・フレーム自体の高さの管理です。 これを誤ると、必要な場合もそうでない場合も、ページ上のコンポーネントに対してスクロール・バーが表示されます。

インライン・フレームの高さを管理するには、コンポーネントで、必要なインライン・フレームの高さをページに指示する必要があります。 リモート・コンポーネントでは、ドメイン間の問題に対応する場合があります。そのため、ページでコンポーネントがレンダリングされた後に、Sites SDKメッセージングを使用して、インライン・フレームを必要な高さに設定するようページに指示する必要があります。 これは、SitesSDK.setProperty('height', {value}) APIを使用して行われます。 (Oracle Content and Expeience SDKsを参照してください。)

たとえば、setHeight関数とカスタム・バインディング・ハンドラを作成して、コンポーネントがページにレンダリングされたときにそれをコールします。

  • 高さ更新関数:

    // set the height of the iFrame for this App
    self.setHeight = function () {
    // use the default calculation or supply your own height value as a second parameter
    SitesSDK.setProperty('height');
    };
  • コンポーネントがページにレンダリングされるたびに、またはプロパティが変更されるたびにsetHeightを呼び出すようにカスタム・バインディング・ハンドラをノック・アウトします:

    ko.bindingHandlers.sampleAppSetAppHeight = {
      update: function (element, valueAccessor, allBindings, viewModel, bindingContext) {
        // create dependencies on any observables so this handler is called whenever it changes
        var imageWidth = viewModel.imageWidth(),
            imageUrl = viewModel.imageUrl(),
            titleText = viewModel.titleText(),
            userText = viewModel.userText();
    
      // re-size the iFrame in the Sites page now the template has rendered
      // Note: If you still see scrollbars in the iframe after this, it is likely that CSS styling in your app is the issue
      viewModel.setHeight();
     }
    };
  • バインディング・ハンドラを呼び出すテンプレート更新:

    <div data-bind="sampleAppSetAppHeight: true"></div>

トリガーおよびアクション登録

インライン・フレーム内にないコンポーネントのトリガー/アクション登録はappinfo.jsonファイルに配置されますが、インライン・フレーム・コンポーネントの場合、コンポーネント自体が、この情報を提供する役目を果たします。 これは、次の2つのAPIを使用して実行します。

SitesSDK.subscribe('GET_ACTIONS', self.getAppActions);
SitesSDK.subscribe('GET_TRIGGERS', self.getAppTriggers);

次に、これらのAPIを使用する例を示します。

    // Register TRIGGERS meta-data
    SampleAppViewModel.prototype.getAppTriggers = function (args) {
      var triggers = [{
        "triggerName": "imageClicked",
        "triggerDescription": "Image clicked",
        "triggerPayload": [{
          "name": "payloadData",
          "displayName": "Trigger Payload Data"
        }]
      }];

      return triggers;
    };

    // Register ACTIONS meta-data
    SampleAppViewModel.prototype.getAppActions = function (args) {
      var actions = [{
        "actionName": "setImageWidth",
        "actionDescription": "Update the image width",
        "actionPayload": [{
          "name": "imageWidth",
          "description": "Image Width in pixels",
          "type": {
            "ojComponent": {
            "component": "ojInputText"
            }
          },
          "value": ""
        }]
      }];

      return actions;
    };

テーマのスタイルへのアクセス

コンポーネントは、インライン・フレーム内でレンダリングされるため、テーマ内で使用可能なスタイルにはアクセスできません。 Sites SDKには、これらのスタイルをインライン・フレーム内の要素に適用できるよう、これらのスタイルを取得するためのAPIが用意されています。

このトピックの詳細は「ステップ14: コンポーネントがインライン・フレームでレンダリングされる場合にカスタム・スタイルを使用」を参照してください。

HTTPS対HTTPプロトコルの混合

Oracle Content ManagementはHTTPSプロトコルを使用するため、ページ内で参照されるすべてのリソースでもHTTPSを使用する必要があります。 リソースには、インライン・フレームでレンダリングされる基本.htmlファイルと、それが参照するすべてのファイルが含まれます。

このリソース要件は、主にリモート・コンポーネントに適用されますが、この制約を知っておく必要があります。 インライン・フレームを使用するローカル・コンポーネントのリソースはOracle Content Managementサーバーによって提供されるため、これらのコンポーネントはすでに一致プロトコルを使用します。

「ステップ14: コンポーネントがインライン・フレームでレンダリングされる場合にカスタム・スタイルを使用」に進みます。