AEM é uma plataforma robusta baseada em 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 se destina a ser 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 em AEM desenvolvimento, consulte o Introdução ao desenvolvimento do AEM Sites - Tutorial do WKND como primeiro passo.
Antes de mergulhar nas tecnologias principais de AEM, a Adobe recomenda concluir a Introdução ao desenvolvimento do AEM Sites - Tutorial do 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 construídos com base em tecnologias Java:
O padrão Java Content Repository (JCR), JSR 283, especifica uma maneira independente de fornecedor e de implementação para acessar o conteúdo de forma bidirecional em um nível granular em um repositório de conteúdo. A Adobe Research (Suíça) AG detém o chumbo da especificação.
O API JCR 2.0 pacote, javax.jcr.*
é usada para acesso direto e manipulação do conteúdo do repositório.
AEM é criado com base em um JCR.
Apache Jackrabbit Oak é uma implementação de um repositório de conteúdo hierárquico escalável e de alto desempenho para uso como a 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 chamado simplesmente de Oak) é a implementação do padrão JCR no qual o AEM é construído.
AEM é criado usando Sling, uma estrutura de aplicação web baseada em princípios REST que fornece fácil desenvolvimento 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 tem contribuído para a Apache Software Foundation - mais informações podem ser encontradas no 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. Isso oferece excelente suporte para autores de conteúdo da Web criarem páginas que são facilmente personalizadas para suas necessidades.
As vantagens dessa flexibilidade são visíveis 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 Gestão de Conteúdo da Web, como o AEM.
Consulte Discover Sling em 15 minutos para os primeiros passos para o desenvolvimento com o Sling.
O diagrama a seguir explica a resolução do script Sling: ele mostra como obter da solicitação HTTP para o nó de conteúdo, do nó de conteúdo para o tipo de recurso, do tipo de recurso para o script e quais variáveis de script estão disponíveis.
O diagrama a seguir explica todos os parâmetros de solicitação ocultos, mas poderosos, que você pode usar ao lidar com o SlingPostServlet
, o manipulador padrão para todas as solicitações do POST que oferece opções infinitas para criar, modificar, excluir, copiar e mover nós no repositório.
O Sling é centrado no conteúdo. Isso significa que o processamento está focado no conteúdo, já que cada solicitação (HTTP) é mapeada no conteúdo na forma de um recurso JCR (um nó de repositório):
Devido a sua filosofia centrada no conteúdo, o Sling implementa um servidor orientado por REST e, portanto, apresenta um novo conceito em estruturas de aplicativos Web. As vantagens são:
No Sling, o processamento é orientado pelo URL da solicitação do usuário. Isso define o conteúdo a ser exibido pelos scripts apropriados. Para fazer isso, as informações são extraídas do URL.
Se analisarmos o seguinte URL:
https://myhost/tools/spy.printable.a4.html/a/b?x=12
Podemos dividi-lo em suas partes compósitas:
protocolo | host | caminho do conteúdo | seletor(s) | extensão | sufixo | param(s) | |||
---|---|---|---|---|---|---|---|---|---|
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 será discutido com mais detalhes nas seções a seguir.
Com o Sling, você especifica qual script renderiza uma determinada entidade (definindo a variável sling:resourceType
no nó JCR). Esse mecanismo oferece mais liberdade do que uma em que o script acessa as entidades de dados (como uma instrução SQL em um script PHP faria), pois um recurso pode ter várias representações.
O pedido é dividido e as informações necessárias são extraídas. O repositório é pesquisado pelo recurso solicitado (nó de conteúdo):
../content/corporate/jobs/developer.html
../content/corporate/jobs/developer
O Sling também permite que outras coisas além dos nós JCR sejam recursos, mas esse é um recurso avançado.
Quando o recurso apropriado (nó de conteúdo) estiver localizado, a variável tipo de recurso sling é extraído. Este é um caminho, que localiza o script a ser usado para renderizar o conteúdo.
O caminho especificado pela variável sling:resourceType
pode ser:
Os caminhos relativos são recomendados pelo Adobe, pois aumentam a portabilidade.
Todos os scripts Sling são armazenados em subpastas de /apps
(mutável, scripts de usuário) ou /libs
(imutável, scripts do sistema), que serão pesquisados nessa ordem.
Alguns outros pontos são:
jobs.POST.esp
A lista de mecanismos de script compatíveis com a instância específica de AEM é listada no Console de Gerenciamento do Felix ( http://<host>:<port>/system/console/slingscripting
).
Usando o exemplo anterior, se a variável sling:resourceType
é hr/jobs
em seguida 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
foi definido em seguida:
ResourceTypeProvider
está ativo).../content/corporate/jobs/developer.html
geraria uma pesquisa em /apps/content/corporate/jobs/
..txt
), HTML (.html
) e JSON (.json
), que listará as propriedades do nó (devidamente formatado). A representação padrão da extensão .res
ou solicitações sem uma extensão de solicitação, é para 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ífico for o jogo, melhor será; em outras palavras, quanto mais seletor corresponder melhor, independentemente de qualquer extensão de solicitação ou correspondência de nome de método.
Por exemplo, considere uma solicitação para acessar o recurso
/content/corporate/jobs/developer.print.a4.html
de tipo
sling:resourceType="hr/jobs"
Supondo que tenhamos 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 pela variável sling:resourceType
(propriedade) também há o super tipo de recurso. Isso geralmente é 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 padrão sling/servlet/default
(usado pelos servlets padrão) é efetivamente a raiz.
O supertipo de recurso de um recurso pode ser definido de duas formas:
sling:resourceSuperType
propriedade do recurso.sling:resourceSuperType
propriedade do nó para o qual 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 do tipo de:
/x
[ c, b, a, <default>]
/y
[ c, a, <default>]
Isso ocorre porque /y
tem sling:resourceSuperType
propriedade /x
não o faz e, portanto, seu supertipo é retirado de seu tipo de recurso.
No Sling, os scripts não podem ser chamados diretamente, pois isso quebraria o conceito restrito de um servidor REST; você misturaria recursos e representações.
Se você chamar a representação (o script) diretamente, oculta o recurso dentro do script, de modo que a estrutura (Sling) não saiba mais sobre ela. Assim, você perde determinados recursos:
POST.jsp
no seu sling:resourceType
localizaçãoIsso usa o pacote da API do Sling, org.apache.sling.*
e bibliotecas de tags.
Uma consideração final é a necessidade de fazer referência a elementos existentes nos scripts.
Scripts mais complexos (agregação de scripts) podem precisar acessar vários recursos (por exemplo, navegação, barra lateral, rodapé, elementos de uma lista) e fazer isso incluindo a variável recurso.
Para fazer isso, você pode usar o sling:include("/<path>/<resource>")
comando. Isso incluirá efetivamente a definição do recurso referenciado.
O OSGi (Open Services Gateway Initiative) define uma arquitetura para o desenvolvimento e implantação de aplicativos e bibliotecas modulares (também conhecida 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 se descubram dinamicamente para colaboração.
Em seguida, uma estrutura OSGi oferece carregamento/descarregamento dinâmico, configuração e controle desses pacotes, sem a necessidade de reinicializações.
Informações completas sobre a tecnologia OSGi podem ser encontradas no site Site do OSGi.
Em particular, a página de 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 de aplicativo. O Sling, e portanto AEM, usa o Apache Felix implementação do OSGi. Ambos são coleções de pacotes OSGi executados em uma estrutura OSGi.
Isso permite executar as seguintes ações em qualquer um dos pacotes da instalação:
Consulte Configuração do OSGi para AEM as a Cloud Service para obter mais informações.
A lista a seguir fornece uma visão geral da estrutura que será exibida no repositório.
/apps
- Aplicações relacionadas; O inclui definições de componentes específicas para o seu site. Os componentes desenvolvidos 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 sobre usuários e grupos./libs
- Bibliotecas e definições que pertencem ao núcleo da 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 criados em /apps
./tmp
- Área de trabalho temporária./var
- Arquivos que mudam e são atualizados pelo sistema; como logs de auditoria, estatísticas, tratamento de eventos.As alterações nessa estrutura, ou nos arquivos dentro dela, devem ser feitas com cuidado. Certifique-se de compreender totalmente as implicações de quaisquer alterações feitas.
Você não deve alterar nada na variável /libs
caminho. Para configuração e outras alterações, copie o item de /libs
para /apps
e fazer quaisquer alterações no /apps
.