Etapa 13: Renderizar um Componente em um iFrame

A amostra exibiu até aqui um componente local renderizado em linha na página. Você também pode optar por renderizar um componente em um iframe.

Por exemplo, você poderá optar por renderizar um componente em um iframe se seu componente fizer atualizações não onipotentes na página, o que exige a recriação da página sempre que as propriedades forem alteradas. Além disso, componentes remotos são sempre renderizados em um iframe.

As amostras nesta seção são obtidas dos arquivos criados para você quando a opção Criar um componente renderizado em um iframe é escolhida ao criar um componente local. No entanto, você pode obter esse conjunto de arquivos e hospedá-los em seu servidor remoto para que eles sejam aplicados igualmente aos componentes remotos.

Semelhanças entre Componentes iFrame e Não iFrame

Painel Definições

Como o painel Definições é sempre colocado na página em um iframe, o código para ele não muda, independentemente de o componente usar ou não um iframe. Você criará o mesmo código do painel Definições para ambos os casos de uso.

API do SDK de Sites

A API do SDK é a mesma para ambos os casos de uso. Você usará o mesmo código para acionar triggers, fazer listening de ações, bem como obter e definir valores de propriedade. Embora algumas propriedades possam não ser aplicáveis a ambos os casos (por exemplo, você não pode definir a propriedade "height" para um componente que não usa um iframe), a API permanece a mesma. Portanto, você pode copiar o código entre esses dois tipos de componentes e o código de exemplo discutido neste tutorial funcionará em ambos os casos.

Diferenças entre Componentes iFrame e Não iFrame

Estrutura e Dependências de Arquivo

Ao selecionar a opção Criar um componente renderizado em um iframe durante a criação de um componente local, você verá os seguintes arquivos criados:
<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

Esses arquivos são criados para permitir que você execute imediatamente seu componente em um iframe na página. As principais diferenças entre essa estrutura e a de um componente local padrão são:

  • Dependências de JavaScript:

    • Você está obtendo uma cópia completa desses arquivos para que seu componente execute. Esses arquivos são obrigatórios para que o componente iframe de amostra seja executado. Você pode adicionar e remover o conteúdo desse diretório com base em seus requisitos.

    • Como todo o conteúdo do diretório assets para seu componente é enviado por push para um site público quando o componente é publicado, todo o conteúdo do diretório js estará disponível no Site Builder e no runtime.

    • Observação: Esses arquivos são criados para facilidade de uso. Examine a consolidação desses arquivos no tema ou em outro local público em vez de criar versões distintas desses arquivos para cada componente de iframe.

  • render.html:

    • Este é um documento HTML completo, ao contrário do arquivo render.js para componentes padrão, que é um módulo AMD.

Gerenciamento da "Altura" do Componente

Um dos problemas de usar um iframe é o gerenciamento de altura do próprio iframe. Se você errar nisso, verá barras de rolagem aparecendo para o componente na página, o que pode desejável ou não.

Para gerenciar a altura do iframe, o componente deve informar para a página a altura desejada do iframe. Com componentes remotos, você pode estar lidando com problemas de domínio cruzado; por isso, use as mensagens do SDK de Sites para solicitar à página que defina o iframe com a altura exigida após a renderização do componente. Isso é feito usando a API SitesSDK.setProperty('height', {value}). (Consulte SDKs do Oracle Content and Experience.)

Por exemplo, crie a função setHeight e um handler de binding personalizado para chamá-la quando o componente for renderizado na página.

  • Atualizar função 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');
    };
  • Handler de binding personalizado do Knockout para chamar setHeight sempre que o componente for renderizado na página ou uma propriedade for alterada:

    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();
     }
    };
  • Atualização de modelo para chamar o handler de binding:

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

Registro de Trigger e Ação

Embora o registro de trigger/ação para componentes que não estão em iframes esteja localizado no arquivo appinfo.json, para componentes de iframe, o próprio componente é responsável por fornecer essa informação. Isso é feito com o uso destas duas APIs:

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

Veja um exemplo de como usar estas 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;
    };

Acesso aos Estilos de Tema

Como o componente é renderizado em um iframe, ele não tem acesso aos estilos disponíveis no tema. O SDK de Sites fornece uma API para recuperar esses estilos; assim, eles podem ser aplicados aos elementos dentro do iframe.

Este tópico é explorado mais em Etapa 14: Usar Estilos Personalizados Quando o Componente é Renderizado em um iFrame.

HTTPS Misto Versus Protocolo HTTP

Como o Oracle Content Management usa o protocolo HTTPS, todos os recursos referenciados na página também devem usar HTTPS. Os recursos incluem o arquivo .html base que será renderizado no iframe com todos os arquivos que ele menciona.

Esse recurso se aplica à maioria dos componentes remotos; no entanto, esteja ciente dessa restrição. Os recursos de componentes locais que usam frames embutidos são fornecidos pelo servidor do Oracle Content Management, ou seja, esses componentes já usam um protocolo correspondente.

Continue em Etapa 14: Usar Estilos Personalizados Quando o Componente é Renderizado em um iFrame.