Paso 13: Representar un componente en un marco en línea

El ejemplo ha mostrado un componente local representado en línea en la página. También puede elegir representar un componente en un marco en línea.

Por ejemplo, puede elegir representar un componente en un marco en línea si su componente realiza actualizaciones secundarias en la página, lo que hace necesario que vuelva a crear la página siempre que cambien las propiedades. Además, los componentes remotos siempre se representan en un marco en línea.

Los ejemplos de esta sección se han tomado de los archivos creados cuando elige la opción Cree un componente que se represente en un iFrame al crear un componente local. Sin embargo, puede alojar este juego de archivos en su servidor remoto para que se apliquen de igual forma en los componentes remotos.

Similitudes entre componentes de marcos en línea y marcos no en línea

Panel de configuración

Dado que el panel de configuración siempre está incluido en la página de un marco en línea, el código del panel de configuración no cambia en función de si el componente emplea un marco en línea o no. Creará el mismo código de panel de configuración para ambos casos de uso.

API de SDK de Sites

La API de SDK es la misma para ambos casos de uso. Usará el mismo código para iniciar disparadores, recibir acciones y obtener y definir los valores de propiedad. Mientras que ciertas propiedades pueden no ser aplicables en ambos casos (por ejemplo, no puede definir la propiedad "height" para un componente que no usa marco en línea), la API sigue siendo la misma. Por lo tanto, puede copiar el código entre estos dos tipos de componentes, y el código de ejemplo mostrado en este tutorial funcionará para ambos.

Diferencias entre componentes de marcos en línea y marcos no en línea

Estructura de archivos y dependencias

Al seleccionar Cree un componente que se represente en un iFrame cuando se crea un componente local, verá que se crean los siguientes archivos:
<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

Estos archivos le permiten ejecutar inmediatamente su componente en un marco en línea en la página. Las diferencias básicas entre esta estructura y la de un componente local estándar son:

  • Dependencias de JavaScript:

    • Obtiene una copia completa de estos archivos para que se ejecute el componente. Estos archivos son necesarios para que se ejecute el componente de marco en línea de ejemplo. Puede agregar y eliminar contenido de este directorio en función de sus necesidades.

    • Dado que todo lo que se encuentre en el directorio assets de su componente se transfiere a un sitio público al publicar el componente, el contenido del directorio js estará disponible tanto en el creador de sitios como en tiempo de ejecución.

    • Nota: Estos archivos se crean para facilitar el uso. Debe consultar la consolidación de estos archivos en el tema o en otra ubicación pública en lugar de crear versiones diferentes de estos archivos para cada uno de los componentes de marcos en línea.

  • render.html:

    • Al contrario que el archivo render.js para componentes estándar, que es un módulo AMD, este es un documento HTML completo.

Gestión de la "altura" del componente

Uno de los problemas de utilizar marcos en línea es la gestión de la altura del propio marco. Si esto no se hace bien, aparecerán barras de desplazamiento para el componente en la página que es posible que desee o no.

Para gestionar la altura del marco en línea, el componente debe indicar a la página la altura que desea para el marco en línea. Cuando los componentes sean remotos, es posible que haya problemas entre dominios, por lo que debe usar mensajes del SDK de Sites para solicitar a la página que defina la altura necesaria después de que el componente se haya representado en la página. Esto se hace empleando la API SitesSDK.setProperty('height', {value}). (ConsulteLos SDK de Oracle Content and Experience).

Por ejemplo, cree la función setHeight y un manejador de enlace personalizado para llamarlo cuando el componente esté representado en la página.

  • Actualizar la función de altura:

    // 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');
    };
  • Para que el manejador de enlace personalizado de Knockout llame a setHeight siempre que se represente el componente en la página o cambie una propiedad:

    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();
     }
    };
  • Actualización de la plantilla para llamar al manejador de enlace:

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

Registro de disparadores y acciones

Mientras que el registro de disparador/acción para componentes que no son de marcos en línea se encuentra en el archivo appinfo.json, en el caso de los componentes de marcos en línea, el propio componente se encarga de proporcionar esta información. Se hace empleando estas dos API:

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

Ejemplo de uso de estas 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;
    };

Acceso a los estilos de tema

Dado que el componente se representa en un marco en línea, no tiene acceso a los estilos disponibles en el tema. El SDK de Sites proporciona una API para recuperar estos estilos, a fin de que puedan aplicarse a elementos del marco en línea.

Se profundiza más sobre este tema en Paso 14: Usar estilos personalizados cuando el componente está representado en un marco en línea.

HTTPS mixta frente al protocolo HTTP

Dado que Oracle Content Management utiliza el protocolo HTTPS, todos los recursos a los que se hace referencia en la página también deben utilizar HTTPS. Los recursos incluyen el archivo base .html que se representará en el marco en línea junto con los archivos a los que hace referencia.

Aunque este requisito se aplica sobre todo a los componentes remotos, debe conocer esta restricción. Los recursos de componentes locales que emplean marcos en línea los proporciona el servidor de Oracle Content Management, por lo que estos componentes ya usan un protocolo coincidente.

Continúe en Paso 14: Usar estilos personalizados cuando el componente está representado en un marco en línea.