Estrutura do componente social social-component-framework

A estrutura do componente social (SCF) simplifica o processo de configuração, personalização e extensão dos componentes do Communities no lado do servidor e no lado do cliente.

Os benefícios do quadro:

Explore em uma instância do autor ou de publicação usando o modelo interativo Guia de componentes da comunidade.

Visão geral overview

No SCF, um componente é composto de um POJO do SocialComponent, um modelo JS Handlebars (para renderizar o componente) e CSS (para estilizar o componente).

Um modelo JS Handlebars pode estender os componentes JS de modelo/visualização para lidar com a interação do usuário com o componente no cliente.

Se um componente precisar suportar a modificação de dados, a implementação da API do SocialComponent poderá ser gravada para suportar a edição/salvamento de dados semelhantes a objetos de modelo/dados em aplicativos web tradicionais. Além disso, as operações (controladores) e um serviço de operação podem ser adicionados para lidar com solicitações de operação, executar lógica de negócios e chamar as APIs nos objetos de modelo/dados.

A API do SocialComponent pode ser estendida para fornecer dados exigidos por um cliente para uma camada de visualização ou um cliente HTTP.

Como as páginas são renderizadas para o cliente how-pages-are-rendered-for-client

Personalização e extensão de componentes component-customization-and-extension

Para personalizar ou estender os componentes, grave somente as sobreposições e extensões no diretório /apps, o que simplifica o processo de atualização para versões futuras.

Estrutura do lado do servidor server-side-framework

A estrutura fornece APIs para acessar funcionalidades no servidor e suportar a interação entre o cliente e o servidor.

APIs Java™ java-apis

As APIs Java™ fornecem classes e interfaces abstratas que são facilmente herdadas ou classificadas em subclasses.

As classes principais são descritas na seção Personalização do lado do servidor página.

Visita Visão geral do provedor de recursos de armazenamento para saber como trabalhar com UGC.

API HTTP http-api

A API HTTP facilita a personalização e a escolha de plataformas de clientes para aplicativos PhoneGap, aplicativos nativos e outras integrações e mashups. Além disso, a API HTTP permite que um site da comunidade seja executado como um serviço sem um cliente, de modo que os componentes da estrutura possam ser integrados em qualquer página da Web criada em qualquer tecnologia.

API HTTP - Solicitações GET http-api-get-requests

Para cada SocialComponent, a estrutura fornece um terminal de API baseado em HTTP. O endpoint é acessado enviando uma solicitação GET para o recurso com um seletor ".social.json" + extensão. Usando o Sling, a solicitação é entregue à DefaultSocialGetServlet.

DefaultSocialGetServlet

GET Request

Um servlet padrão do GET escuta solicitações .social.json às quais o SocialComponent responde com um JSON personalizável.

API HTTP - Solicitações POST http-api-post-requests

Além das operações de GET (Leitura), a estrutura define um padrão de ponto de extremidade para permitir outras operações em um componente, incluindo Criar, Atualizar e Excluir. Esses endpoints são APIs HTTP que aceitam entrada e respondem com um código de status HTTP ou com um objeto de resposta JSON.

Esse padrão de endpoint da estrutura torna as operações de CUD extensíveis, reutilizáveis e testáveis.

POST Request

Há um Sling POST:operation para cada operação do SocialComponent. A lógica de negócios e o código de manutenção de cada operação são envolvidos em um OperationService acessível por meio da API HTTP ou de outro lugar como um serviço OSGi. Ganchos são fornecidos com suporte a extensões de operação conectáveis para ações antes/depois.

Provedor de recurso de armazenamento (SRP, Storage Resource Provider) storage-resource-provider-srp

Para saber mais sobre a manipulação de UGC armazenados no armazenamento de conteúdo da comunidade, consulte:

Personalizações do lado do servidor server-side-customizations

Visita Personalizações do lado do servidor para obter informações sobre como personalizar a lógica de negócios e o comportamento de um componente Comunidades no lado do servidor.

Linguagem de modelo JS do Handlebars handlebars-js-templating-language

Uma das alterações mais visíveis do novo quadro é a utilização do Handlebars JS Linguagem de modelo (HBS), uma tecnologia popular de código aberto para renderização de servidor-cliente.

Os scripts HBS são simples, sem lógica, compilados no servidor e no cliente, são fáceis de sobrepor e personalizar e se vinculam naturalmente ao UX do cliente, pois o HBS oferece suporte à renderização no lado do cliente.

O quadro prevê vários Handlebars helpers que são úteis ao desenvolver SocialComponents.

No servidor, quando o Sling resolve uma solicitação do GET, ele identifica o script usado para responder à solicitação. Se o script for um modelo HBS (.hbs), o Sling delegará a solicitação ao mecanismo Handlebars. O mecanismo Handlebars obtém o SocialComponent do SocialComponentFactory apropriado, cria um contexto e renderiza o HTML.

Sem restrição de acesso no-access-restriction

Os arquivos de modelo Handlebars (HBS) (.hbs) são análogos aos arquivos de modelo .jsp e .html, exceto que podem ser usados para renderização tanto no navegador do cliente quanto no servidor. Portanto, um navegador cliente que solicita um modelo do lado do cliente recebe um arquivo .hbs do servidor.

Isso requer que todos os modelos HBS no caminho de pesquisa do sling (qualquer arquivo .hbs em /libs/ ou /apps) possam ser buscados por qualquer usuário do autor ou da publicação.

O acesso HTTP a arquivos .hbs não pode ser proibido.

Adicionar ou incluir um componente das comunidades add-or-include-a-communities-component

A maioria dos componentes das comunidades deve ser adicionado como um recurso endereçável do Sling. Alguns poucos componentes das Comunidades podem ser incluído em um modelo como um recurso não existente para permitir a inclusão dinâmica e a personalização do local no qual gravar conteúdo gerado pelo usuário (UGC).

Em ambos os casos, as propriedades do componente bibliotecas de clientes necessárias também devem estar presentes.

Adicionar um componente

Adicionar um componente refere-se ao processo de adicionar uma instância de um recurso (componente), como quando arrastado do navegador de componentes (sidekick) para uma página no modo de edição do autor.

O resultado é um nó filho JCR em um nó par, que é endereçável Sling.

Incluir um componente

Incluir um componente refere-se ao processo de adicionar uma referência a um recurso "não existente" (nenhum nó JCR) no modelo, como usar uma linguagem de script.

A partir do Adobe Experience Manager (AEM) 6.1, quando um componente é incluído dinamicamente em vez de adicionado, é possível editar as propriedades do componente no autor design modo.

Somente alguns componentes selecionados do AEM Communities podem ser incluídos dinamicamente. São eles:

A variável Guia de componentes da comunidade permite que componentes incluíveis sejam alternados de adicionados para serem incluídos.

Ao usar Handlebars linguagem de modelo, o recurso não existente é incluído usando o incluir auxiliar especificando o resourceType:

{{include this.id path="comments" resourceType="social/commons/components/hbs/comments"}}

Ao usar JSP, um recurso é incluído usando a tag cq:include:

<cq:include path="votes"
 resourceType="social/tally/components/voting" />

Handlebars Helpers handlebars-helpers

Consulte Auxiliares de Handlebars SCF para obter uma lista e uma descrição dos auxiliares personalizados disponíveis no SCF.

Estrutura do lado cliente client-side-framework

Estrutura JavaScript de visualização de modelo model-view-javascript-framework

O quadro inclui uma extensão do Backbone.js, uma estrutura JavaScript com visualização de modelo, para facilitar o desenvolvimento de componentes avançados e interativos. A natureza orientada a objetos suporta uma estrutura extensível/reutilizável. A comunicação entre cliente e servidor é simplificada com a API HTTP.

A estrutura usa modelos Handlebars do lado do servidor para renderizar os componentes para o cliente. Os modelos são baseados nas respostas JSON geradas pela API HTTP. As visualizações se vinculam ao HTML gerado pelos modelos Handlebars e fornecem interatividade.

Convenções CSS css-conventions

As convenções recomendadas a seguir para definir e usar classes CSS:

Personalizações do lado do cliente client-side-customizations

Para personalizar a aparência e o comportamento de um componente do Communities no lado do cliente, consulte Personalizações do lado do cliente, que inclui informações sobre:

Fundamentos de recursos e componentes feature-and-component-essentials

As informações essenciais para desenvolvedores estão descritas na seção Fundamentos de recursos e componentes seção.

Informações adicionais do desenvolvedor podem ser encontradas na Diretrizes de codificação seção.

Resolução de problemas troubleshooting

As preocupações comuns e os problemas conhecidos são descritos no Solução de problemas seção.