O AEM é uma plataforma robusta criada com tecnologias comprovadas, escaláveis e flexíveis. Este documento fornece uma visão geral detalhada das várias partes que compõem o AEM e serve como um apêndice técnico para um desenvolvedor de AEM de pilha completa. Não se destina a ser um guia de introdução. Se você é novo no desenvolvimento do AEM, consulte Introdução ao desenvolvimento do AEM Sites - Tutorial do WKND como um primeiro passo.
Antes de mergulhar nas tecnologias principais do AEM, Adobe recomenda completar o Introdução ao desenvolvimento do AEM Sites - Tutorial de WKND.
Como um sistema moderno de gerenciamento de conteúdo, o AEM depende de tecnologias padrão da Web:
O repositório de conteúdo subjacente e as camadas de lógica de negócios são criados com base em tecnologias Java™:
O Java™ Content Repository (JCR) padrão, JSR 283, especifica uma maneira independente de fornecedor e de implementação para acessar o conteúdo de forma bidirecional em nível granular em um repositório de conteúdo. O líder da especificação é da Adobe Research (Switzerland) AG.
A variável API JCR 2.0 pacote, javax.jcr.*
O é usado para o acesso direto e manipulação de conteúdo do repositório.
O AEM é baseado em um JCR.
Apache Jackrabbit Oak O é uma implementação de um repositório de conteúdo hierárquico dimensionável e de alto desempenho para uso como base de sites modernos de classe mundial e outros aplicativos de conteúdo exigentes, em conformidade com o padrão JCR.
Jackrabbit Oak (também conhecido simplesmente como Oak), é a implementação do padrão JCR sobre o qual o AEM é construído.
O AEM é construído usando Sling, uma estrutura de aplicativo web baseada em princípios REST que fornece desenvolvimento fácil de aplicativos orientados a conteúdo. O Sling usa um repositório JCR, como o Apache Jackrabbit Oak, como seu armazenamento de dados. O Sling contribuiu para a Apache Software Foundation - mais informações podem ser encontradas na Apache.
Usando o Sling, o tipo de conteúdo a ser renderizado não é a primeira consideração de processamento. Em vez disso, a principal consideração é se o URL resolve um objeto de conteúdo para o qual um script pode ser encontrado para executar a renderização. Esse processo oferece excelente suporte para que os autores de conteúdo da Web criem páginas que são facilmente personalizadas de acordo com suas necessidades.
As vantagens dessa flexibilidade são evidentes em aplicativos com uma grande variedade de elementos de conteúdo diferentes, ou quando você precisa de páginas que possam ser facilmente personalizadas. Especificamente, ao implementar um sistema de Gerenciamento de conteúdo da Web como o AEM.
Consulte Descubra o Sling em 15 minutos para conhecer as primeiras etapas de desenvolvimento com o Sling.
O diagrama a seguir explica a resolução do script Sling. Ele mostra como ir da solicitação HTTP ao nó de conteúdo, do nó de conteúdo ao tipo de recurso, do tipo de recurso ao script e quais variáveis de script estão disponíveis.
O diagrama a seguir explica os parâmetros de solicitação ocultos, mas eficientes, que você pode usar com o SlingPostServlet
, o manipulador padrão para todas as solicitações de POST. O manipulador fornece opções infinitas para criar, modificar, excluir, copiar e mover nós no repositório.
O Sling está centrado no conteúdo. Isso significa que o processamento se concentra no conteúdo à medida que cada solicitação (HTTP) é mapeada no conteúdo na forma de um recurso JCR (um nó de repositório):
Devido à sua filosofia centrada no conteúdo, o Sling implementa um servidor orientado para REST e, portanto, apresenta um novo conceito em estruturas de aplicações Web. As vantagens são:
No Sling, o processamento é orientado pelo URL da solicitação do usuário. Ele define o conteúdo a ser exibido pelos scripts apropriados e as informações são extraídas do URL.
Análise do seguinte URL:
https://myhost/tools/spy.printable.a4.html/a/b?x=12
Você pode separá-la em suas partes compostas:
protocolo | host | caminho do conteúdo | seletores | extensão | sufixo | params | |||
---|---|---|---|---|---|---|---|---|---|
https:// |
myhost |
/ |
tools/spy |
.printable.a4. |
html |
/ |
a/b |
? |
x=12 |
tools/spy.html
Usando os princípios de decomposição de URL:
A figura a seguir ilustra o mecanismo usado, que é discutido com mais detalhes nas seções a seguir.
Com o Sling, você especifica qual script renderiza uma determinada entidade (definindo o sling:resourceType
no nó JCR). Este mecanismo oferece mais liberdade do que um em que o script acessa as entidades de dados (como uma instrução SQL em um script PHP faria) como um recurso pode ter várias representações.
O pedido é detalhado e as informações necessárias são extraídas. O repositório é pesquisado para o recurso solicitado (nó de conteúdo):
../content/corporate/jobs/developer.html
../content/corporate/jobs/developer
O Sling também permite que outros itens além dos nós JCR sejam recursos, mas essa funcionalidade é um recurso avançado.
Quando o recurso apropriado (nó de conteúdo) for localizado, a variável tipo de recurso sling é extraído. Esse caminho localiza o script a ser usado para renderizar o conteúdo.
O caminho especificado pelo sling:resourceType
pode ser:
Os caminhos relativos são recomendados pelo Adobe à medida que aumentam a portabilidade.
Todos os scripts Sling são armazenados em subpastas de /apps
(mutável, scripts do usuário) ou /libs
(imutável, scripts de sistema), que é pesquisado nesta ordem.
Alguns outros pontos a observar são:
jobs.POST.esp
A lista de mecanismos de script compatíveis com determinada instância do AEM está listada no Felix Management Console ( http://<host>:<port>/system/console/slingscripting
).
Usando o exemplo anterior, se a variável sling:resourceType
é hr/jobs
depois para:
.html
(tipos de solicitação padrão, formato padrão)
/apps/hr/jobs/jobs.esp
; a última seção do sling:resourceType
forma o nome do arquivo./apps/hr/jobs/jobs.POST.esp
..html
../content/corporate/jobs/developer.pdf
/apps/hr/jobs/jobs.pdf.esp
; o sufixo é adicionado ao nome do script.print
; como em ../content/corporate/jobs/developer.print.html
/apps/hr/jobs/jobs.print.esp
; o seletor é adicionado ao nome do script.sling:resourceType
é definida como:
ResourceTypeProvider
está ativo).../content/corporate/jobs/developer.html
geraria uma pesquisa em /apps/content/corporate/jobs/
..txt
), HTML (.html
) e JSON (.json
), que lista as propriedades do nó (adequadamente formatadas). A representação padrão da extensão .res
, ou solicitações sem uma extensão de solicitação, é fazer spool do recurso (quando possível)./apps/sling/servlet/errorhandler
para scripts personalizados/libs/sling/servlet/errorhandler/404.jsp
Se vários scripts se aplicarem a uma determinada solicitação, o script com a melhor correspondência será selecionado. Quanto mais específica for uma correspondência, melhor ela será; em outras palavras, quanto mais o seletor corresponder melhor, independentemente de qualquer correspondência de extensão de solicitação ou nome de método.
Por exemplo, considere uma solicitação para acessar o recurso
/content/corporate/jobs/developer.print.a4.html
Do tipo
sling:resourceType="hr/jobs"
Supondo que você tenha a seguinte lista de scripts no local correto:
GET.esp
jobs.esp
html.esp
print.esp
print.html.esp
print/a4.esp
print/a4/html.esp
print/a4.html.esp
Em seguida, a ordem de preferência seria (8) - (7) - (6) - (5) - (4) - (3) - (2) - (1).
Além dos tipos de recursos (definidos principalmente pelo sling:resourceType
), também há o supertipo de recurso. Esse tipo é indicado pela variável sling:resourceSuperType
propriedade. Esses supertipos também são considerados ao tentar encontrar um script. A vantagem dos supertipos de recursos é que eles podem formar uma hierarquia de recursos em que o tipo de recurso default sling/servlet/default
(usado pelos servlets padrão) é efetivamente a raiz.
O supertipo de recurso de um recurso pode ser definido de duas maneiras:
sling:resourceSuperType
propriedade do recurso.sling:resourceSuperType
propriedade do nó para o qual a variável sling:resourceType
pontos.Por exemplo:
/
a
b
sling:resourceSuperType = a
c
sling:resourceSuperType = b
x
sling:resourceType = c
y
sling:resourceType = c
sling:resourceSuperType = a
A hierarquia de tipo de:
/x
[ c, b, a, <default>]
/y
[ c, a, <default>]
O motivo é porque /y
tem o sling:resourceSuperType
propriedade, enquanto /x
não faz e, portanto, seu supertipo é retirado de seu tipo de recurso.
No Sling, os scripts não podem ser chamados diretamente porque quebrariam o conceito estrito de um servidor REST; você misturaria recursos e representações.
Se você chamar a representação (o script) diretamente, ocultará o recurso dentro do script para que a estrutura (Sling) não saiba mais sobre ela. Dessa forma, você perde determinados recursos:
POST.jsp
script em seu sling:resourceType
localizaçãoUsa o pacote da API Sling, org.apache.sling.*
e bibliotecas de tags.
Uma consideração final é a necessidade de fazer referência aos elementos existentes nos scripts.
Os scripts mais complexos (agregação de scripts) acessam vários recursos (por exemplo, navegação, barra lateral, rodapé, elementos de uma lista) e fazem isso incluindo o recurso.
Nesse caso, você pode usar a variável sling:include("/<path>/<resource>")
comando. Ele inclui efetivamente a definição do recurso referenciado.
O OSGi (Open Services Gateway Initiative) define uma arquitetura para desenvolver e implantar aplicativos e bibliotecas modulares (também é conhecido como Dynamic Module System for Java™). Os contêineres OSGi permitem dividir o aplicativo em módulos individuais (são arquivos jar com informações meta adicionais e chamados de pacotes na terminologia OSGi) e gerenciar as dependências cruzadas entre eles com:
Esses serviços e contratos fornecem uma arquitetura que permite que elementos individuais descubram dinamicamente uns aos outros para colaboração.
Uma estrutura OSGi oferece carregamento/descarregamento dinâmico, configuração e controle desses pacotes, sem exigir reinicializações.
Informações completas sobre a tecnologia OSGi podem ser encontradas no site Site OSGi.
Em particular, a página Educação Básica contém uma coleção de apresentações e tutoriais.
Essa arquitetura permite estender o Sling com módulos específicos do aplicativo. O Sling e, portanto, o AEM, usam o Apache Felix implementação do OSGi. Ambas as coleções de pacotes OSGi são executadas em uma estrutura OSGi.
Essa funcionalidade permite executar as seguintes ações em qualquer um dos pacotes da sua instalação:
Consulte Configuração do OSGi para o AEM as a Cloud Service para obter mais informações.
A lista a seguir fornece uma visão geral da estrutura que você vê no repositório.
/apps
- Relacionado ao aplicativo; inclui definições de componentes específicas do site. Os componentes que você desenvolve podem ser baseados nos componentes prontos para uso disponíveis em /libs/core/wcm/components
./content
- Conteúdo criado para o seu site./etc
/home
- Informações de usuários e grupos./libs
- Bibliotecas e definições que pertencem ao núcleo do AEM. As subpastas em /libs
representam os recursos de AEM prontos para uso. O conteúdo em /libs
não pode ser modificado. Os recursos específicos do seu site devem ser feitos em /apps
./tmp
- Espaço de trabalho temporário./var
- Arquivos que são alterados e atualizados pelo sistema, como registros de auditoria, estatísticas, manipulação de eventos.As alterações nessa estrutura ou nos arquivos dentro dela devem ser feitas com cuidado. Certifique-se de entender totalmente as implicações de qualquer alteração feita.
Não altere nada no /libs
caminho. Para configurações e outras alterações, copie o item de /libs
para /apps
e fazer alterações no /apps
.