Schritt 13: Komponente in einem Inlineframe rendern

Bisher hat der Beispielcode eine lokale Komponente inline auf der Seite gerendert. Sie können eine Komponente auch in einem Inlineframe rendern.

Beispiel: Sie können eine Komponente in einem Inlineframe rendern, wenn die Komponente kleinere Aktualisierungen der Seite vornimmt. Dabei müssen Sie die Seite bei allen Eigenschaftsänderungen erneut erstellen. Darüber hinaus werden Remotekomponenten immer in einem Inlineframe gerendert.

Die Beispiele in diesem Abschnitt stammen aus den Dateien, die erstellt werden, wenn Sie die Option Erstellen Sie eine Komponente, die in einem IFrame wiedergegeben wird beim Erstellen einer lokalen Komponente auswählen. Sie können diese Dateien jedoch auch auf dem Remoteserver hosten, damit sie gleichermaßen auf Remotekomponenten angewendet werden.

Gemeinsamkeiten von Inlineframe- und anderen Komponenten

Einstellungsbereich

Da der Einstellungsbereich immer in einem Inlineframe auf der Seite abgelegt wird, ändert sich der Code für den Einstellungsbereich nicht, unabhängig davon, ob die Komponente einen Inlineframe verwendet oder nicht. Sie erstellen denselben Einstellungsbereichscode für beide Anwendungsfälle.

Sites-SDK-API

Die SDK-API ist für beide Anwendungsfälle gleich. Sie verwenden denselben Code für das Auslösen von Triggern, das Listening auf Aktionen und das Abrufen und Festlegen von Eigenschaftswerten. Auch wenn bestimmte Eigenschaften unter Umständen nicht in beiden Fällen anwendbar sind (Sie können z.B. nicht die Eigenschaft "height" für eine Komponente festlegen, die keinen Inlineframe verwendet), bleibt die API gleich. Daher können Sie den Code zwischen beiden Komponententypen kopieren. Der Beispielcode aus diesem Tutorial funktioniert in beiden Fällen.

Unterschiede zwischen Inlineframe- und anderen Komponenten

Dateistruktur und Abhängigkeiten

Wenn Sie Erstellen Sie eine Komponente, die in einem IFrame wiedergegeben wird beim Erstellen einer lokalen Komponente auswählen, werden die folgenden Dateien erstellt:

<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

Mit diesen Dateien können Sie die Komponente sofort in einem Inlineframe auf der Seite ausführen. Hauptunterschiede zwischen dieser Struktur und der einer lokalen Standardkomponente:

JavaScript-Abhängigkeiten:
- Sie erhalten eine vollständige Kopie dieser Dateien, damit die Komponente ausgeführt werden kann. Diese Dateien sind erforderlich, damit die Inlineframe-Beispielkomponente ausgeführt werden kann. Sie können den Inhalt dieses Verzeichnisses je nach Ihren Anforderungen hinzufügen und entfernen.
- Da alle Elemente unter dem Verzeichnis assets für die Komponente beim Veröffentlichen der Komponente an eine öffentliche Site übertragen werden, sind alle Elemente im Verzeichnis js sowohl in Sitebuilder als auch zur Laufzeit verfügbar.
- Hinweis: Diese Dateien werden aus Gründen der Benutzerfreundlichkeit erstellt. Sie sollten diese Dateien im Theme oder in einem anderen öffentlichen Speicherort konsolidieren, anstatt separate Versionen der Dateien für jede Inlineframe-Komponente zu erstellen.
render.html:
- Dies ist ein vollständiges HTML-Dokument im Gegensatz zur Datei render.js für Standardkomponenten, die ein AMD-Modul ist.

Verwaltung der Komponentenhöhe ("height")

Eines der Probleme bei Verwendung eines Inlineframes ist die Verwaltung der Höhe des Inlineframes selbst. Wenn Sie diese falsch einstellen, werden (eventuell unerwünschte) Bildlaufleisten für die Komponente auf der Seite angezeigt.

Um die Höhe des Inlineframes zu verwalten, muss die Komponente angeben, wie hoch der Inlineframe sein soll. Bei Remotekomponenten treten unter Umständen domainübergreifende Probleme auf. Daher müssen Sie Sites-SDK-Messaging verwenden, damit die Seite den Inlineframe auf die erforderliche Höhe setzt, nachdem die Komponente auf der Seite gerendert wurde. Dazu verwenden Sie die SitesSDK.setProperty('height', {value})-API. (Siehe Oracle Content and Experience-SDKs.)

Beispiel: Erstellen Sie die setHeight-Funktion und einen benutzerdefinierten Binding Handler, der diese aufruft, wenn die Komponente auf der Seite gerendert wurde.

Funktion zur Höhenaktualisierung:

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

Benutzerdefinierter Knockout-Binding Handler zum Aufrufen von setHeight, wenn die Komponente auf der Seite gerendert oder eine Eigenschaft geändert wird:

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();
 }
};

Vorlagenaktualisierung zum Aufruf des Binding Handlers:
```
<div data-bind="sampleAppSetAppHeight: true"></div>
```

Trigger- und Aktionsregistrierung

Bei Komponenten, die sich nicht in Inlineframes befinden, erfolgt die Trigger-/Aktionsregistrierung in der Datei appinfo.json. Bei Inlineframe-Komponenten muss die Komponente selbst diese Informationen angeben. Dazu werden die beiden folgenden APIs genutzt:

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

Hier sehen Sie ein Beispiel für die Verwendung dieser APIs.

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

Zugriff auf Theme-Stile

Da die Komponente in einem Inlineframe gerendert wird, hat sie keinen Zugriff auf die im Theme verfügbaren Stile. Das Sites-SDK umfasst eine API, mit der Sie diese Stile abrufen und auf Elemente im Inlineframe anwenden können.

Mehr zu diesem Thema erfahren Sie unter Schritt 14: Benutzerdefinierte Stile verwenden, wenn die Komponente in einem Inlineframe gerendert wird.

Mischung aus HTTPS- und HTTP-Protokoll

Da Oracle Content Management das HTTPS-Protokoll verwendet, müssen alle in der Seite referenzierten Ressourcen ebenfalls HTTPS verwenden. Zu den Ressourcen gehören die .html-Basisdatei, die im Inlineframe gerendert wird, und alle davon referenzierten Dateien.

Diese Ressourcenanforderung gilt in erster Linie für Remotekomponenten. Sie müssen sich dieser Einschränkung allerdings bewusst sein. Ressourcen für lokale Komponenten, die Inlineframes verwenden, werden vom Oracle Content Management-Server bereitgestellt. Diese Komponenten verwenden also bereits ein übereinstimmendes Protokoll.

Weiter mit Schritt 14: Benutzerdefinierte Stile verwenden, wenn die Komponente in einem Inlineframe gerendert wird.