Steg 13: Återge en komponent i en iframe

Så här långt har exemplet visat en lokal komponent som återges infogad på sidan. Du kan även välja att återge en komponent i en iframe.

Du kan till exempel välja att återge en komponent i en iframe om komponenten utför icke-omnipotenta uppdateringar på sidan, som kräver att du återskapar sidan närhelst egenskaperna ändras. Dessutom återges fjärrkomponenter alltid i en iframe.

Exemplen i det här avsnittet är hämtade från filer som skapas för dig när du väljer alternativet Skapa en komponent som återges i en iframe i samband med att du skapar en lokal komponent. Du kan dock ta den här uppsättningen filer och värdhålla dem på fjärrservern, så att de tillämpas i lika hög grad på fjärrkomponenter.

Likheter mellan iframekomponenter och icke-iframekomponenter

Panelen Inställningar

Eftersom panelen Inställningar alltid placeras på sidan i en iframe, ändras inte koden för panelen Inställningar, oavsett om komponenten använder en iframe eller inte. Du skapar samma inställningspanelkod för båda användningsfallen.

API-gränssnitt för SDK:t för webbplatser

SDK-API:t är detsamma för båda användningsfallen. Du använder samma kod för att orsaka triggrar, lyssna efter åtgärder och hämta och ange egenskapsvärden. Även om vissa egenskaper kanske inte är tillämpliga i båda fallen (du kan till exempel inte ange egenskapen "height" för en komponent som inte använder någon iframe), förblir API-gränssnittet detsamma. Därför kan du kopiera koden mellan dessa båda typer av komponenter, och den exempelkod som diskuteras i den här handledningen fungerar för båda fallen.

Skillnader mellan iframekomponenter och icke-iframekomponenter

Filstruktur och beroenden

När du väljer Skapa en komponent som återges i en iframe i samband med att du skapar en lokal komponent ser du följande filer som skapas för dig:
<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

Dessa filer skapas för att du omedelbart ska kunna köra komponenten i en iframe på sidan. De huvudsakliga skillnaderna mellan den här strukturen och den hos en lokal standardkomponent är följande:

  • JavaScript-beroenden:

    • Du får en fullständig kopia av dessa filer så att komponenten kan köras. Dessa filer krävs för att exempeliframekomponenten ska kunna köras. Du kan lägga till och ta bort innehållet i den här katalogen baserat på dina behov.

    • Eftersom allting under katalogen assets för komponenten pushas till en allmän webbplats när komponenten publiceras blir allting i katalogen js tillgängligt både i webbplatsverktyget och vid exekvering.

    • Obs! Dessa filer skapas för förbättrad användarvänlighet. Du bör tänka på att konsolidera dessa filer i temat eller på någon annan allmän plats, snarare än att skapa separata versioner av dessa filer för var och en av iframekomponenterna.

  • render.html:

    • Det här är ett fullständigt HTML-dokument, till skillnad från filen render.js för standardkomponenter, som är en AMD-modul.

Hantering av "höjd" för komponenten

Ett av problemen med att använda en iframe är höjdhanteringen för själva iframen. Om det här blir fel visas rullningslister för komponenten på sidan, vilket du kanske vill ha eller vill undvika.

För att hantera iframens höjd måste komponenten tala om för sidan hur hög den vill att iframen ska vara. Med fjärrkomponenter kan du stöta på problem mellan domäner, så du måste använda meddelandehanteringen i SDK:t för webbplatser för att be sidan att ange korrekt höjd för iframen efter att komponenten har återgetts på sidan. Detta görs med hjälp av API-gränssnittet SitesSDK.setProperty('height', {value}). (Se SDK:er för Oracles moln för innehåll och upplevelse.)

Du kan till exempel skapa funktionen setHeight och en anpassad bindningshanterare för att anropa den när komponenten har återgetts på sidan.

  • Funktion för höjduppdatering:

    // 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');
    };
  • Anpassad bindningshanterare i Knockout för att anropa setHeight närhelst komponenten återges på sidan eller en egenskap ändras:

    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();
     }
    };
  • Malluppdatering för att anropa bindningshanterare:

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

Trigger- och åtgärdsregistrering

För komponenter som inte är placerade i iframes finns registreringen av triggrar/åtgärder i filen appinfo.json, men för iframekomponenter är det själva komponenten som ansvarar för att tillhandahålla denna information. Detta görs med hjälp av dessa två API-gränssnitt:

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

Här är ett exempel på hur du använder dessa API-gränssnitt.

    // 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;
    };

Åtkomst till temaformat

Eftersom komponenten återges i en iframe har den inte åtkomst till de format som finns tillgängliga i temat. SDK:t för webbplatser tillhandahåller ett API-gränssnitt för hämtning av dessa format, så att de kan tillämpas på element inom iframen.

Det här ämnet utforskas närmare i Steg 14: Använd anpassade format när komponenten återges i en iframe.

Blandade HTTPS-protokoll kontra HTTP-protokoll

Eftersom Oracle Content Management använder HTTPS-protokollet måste alla resurser som det refereras till på sidan också använda HTTPS. Resurserna inkluderar .html-basfilen som återges i iframen jämte alla de filer som den refererar till.

Det här resurskravet gäller främst för fjärrkomponenter, men du måste vara medveten om denna begränsning. Resurser för lokala komponenter som använder iframe tillhandahålls av servern för Oracle Content Management, så dessa komponenter använder redan ett matchande protokoll.

Fortsätt till Steg 14: Använd anpassade format när komponenten återges i en iframe.