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
<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.