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 é projetado como um apêndice técnico para um desenvolvedor AEM pilha completa. Não é destinado a um guia de introdução. Se você é novo em AEM desenvolvimento, consulte Introdução ao desenvolvimento do AEM Sites - Tutorial WKND como uma primeira etapa.
Antes de mergulhar nas tecnologias principais da AEM, a Adobe recomenda concluir o Tutorial de desenvolvimento do AEM Sites - WKND.
Como um sistema de gestões de conteúdo moderno, AEM depende de tecnologias da Web padrão:
O repositório de conteúdo subjacente e as camadas de lógica comercial são criados em torno das tecnologias Java:
O padrão Java Content Repository (JCR), JSR 283, especifica uma maneira independente do 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. O chumbo da especificação é detido pela Adobe Research (Suíça) AG.
O pacote JCR API 2.0, javax.jcr.*
é usado para acesso direto e manipulação do conteúdo do repositório.
AEM é construído sobre um JCR.
Apache Jackrabbit Oakis é uma implementação de um repositório de conteúdo hierárquico escalável e de alto desempenho para uso como base de sites modernos de classe mundial e outras aplicações exigentes de conteúdo, em conformidade com o padrão JCR.
Jackrabbit Oak (também chamado simplesmente de Oak), é a implementação do padrão JCR sobre o qual 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. A Sling usa um repositório JCR, como o Apache Jackrabbit Oak, como armazenamento de dados. A Sling contribuiu para a Apache Software Foundation - mais informações estão disponíveis 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 é resolvido para 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 para criar páginas que são facilmente personalizadas para 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. Em particular, ao implementar um sistema de Gestão de conteúdo da Web como o AEM.
Consulte Discover Sling em 15 minutos para obter as primeiras etapas para desenvolver 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 SlingPostServlet
, o manipulador padrão para todas as solicitações de POST que oferecem opções intermináveis 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) está mapeada para o 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 por REST e, portanto, apresenta um novo conceito em estruturas de aplicativos da Web. As vantagens são:
No Sling, o processamento é conduzido 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 compostas:
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 utilizado, que será discutido mais pormenorizadamente nas seções a seguir.
Com o Sling, você especifica qual script renderiza uma determinada entidade (definindo a propriedade sling:resourceType
no nó JCR). Esse mecanismo oferta 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 execuções.
O pedido é discriminado 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 outros nós que não o JCR sejam recursos, mas esse é um recurso avançado.
Quando o recurso apropriado (nó de conteúdo) estiver localizado, o tipo de recurso sling será extraído. Esse é um caminho, que localiza o script a ser usado para renderizar o conteúdo.
O caminho especificado por 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 de sistema), que serão pesquisados nessa ordem.
Alguns outros pontos são:
jobs.POST.esp
A lista de mecanismos de script suportados pela instância específica do AEM está listada no Console de Gerenciamento Felix ( http://<host>:<port>/system/console/slingscripting
).
Usando o exemplo anterior, se sling:resourceType
for hr/jobs
, então para:
.html
(tipos de solicitação padrão, formato padrão)
/apps/hr/jobs/jobs.esp
; a última seção de 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
tiver sido definido, então:
ResourceTypeProvider
estiver ativo).../content/corporate/jobs/developer.html
geraria uma pesquisa em /apps/content/corporate/jobs/
..txt
), HTML (.html
) e JSON (.json
), todos os quais serão listas nas propriedades do nó (formatados adequadamente). A renderização padrão para a 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 o seletor corresponder melhor, independentemente de qualquer extensão de solicitação ou nome de método correspondente.
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 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 primariamente pela propriedade sling:resourceType
), há também o supertipo de recurso. Isso é geralmente indicado pela propriedade sling:resourceSuperType
. 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 na qual 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
do recurso.sling:resourceSuperType
do nó ao qual sling:resourceType
aponta.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 tipos de:
/x
[ c, b, a, <default>]
/y
[ c, a, <default>]
Isso ocorre porque /y
tem a propriedade sling:resourceSuperType
, ao passo que /x
não tem 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 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 ele. Assim, você perde determinados recursos:
POST.jsp
no local sling:resourceType
Isso usa o pacote Sling API, org.apache.sling.*
e as bibliotecas de tags.
Uma consideração final é a necessidade de fazer referência aos elementos existentes nos scripts.
Scripts mais complexos (como a 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 o recurso.
Para fazer isso, você pode usar o comando sling:include("/%3Cpath%3E/%3Cresource%3E?lang=pt-BR")
. Isso incluirá 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 conhecida como Dynamic Module System for Java). Os container OSGi permitem que você divida seu aplicativo em módulos individuais (são arquivos jar com informações meta adicionais e chamados de pacotes na terminologia OSGi) e gerencie 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 oferta o carregamento/descarregamento dinâmico, a configuração e o controle desses pacotes - sem a necessidade de reinicializações.
Informações completas sobre a tecnologia OSGi podem ser encontradas no 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 do aplicativo. Sling e, portanto, AEM, usa a implementação Apache Felix 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 sua instalação:
Consulte Configurando o OSGi para AEM como Cloud Service para obter mais informações.
A lista a seguir fornece uma visão geral da estrutura que você verá no repositório.
/apps
- Aplicações relacionadas; inclui definições de componentes específicas ao seu site. Os componentes que você desenvolve podem ser baseados nos componentes prontos disponíveis em /libs/core/wcm/components
./content
- Conteúdo criado para seu site./etc
/home
- Informações do usuário e do grupo./libs
- Bibliotecas e definições que pertencem ao núcleo da AEM. As subpastas em /libs
representam os recursos predefinidos AEM. O conteúdo em /libs
não pode ser modificado. Os recursos específicos do site devem ser criados em /apps
./tmp
- Área de trabalho temporária./var
- Arquivos que mudam e são atualizados pelo sistema; como registros de auditoria, estatísticas, tratamento de eventos.As alterações nesta estrutura, ou nos arquivos nela contidos, devem ser feitas com cuidado. Certifique-se de compreender totalmente as implicações de quaisquer alterações feitas.
Você não deve alterar nada no caminho /libs
. Para configurações e outras alterações, copie o item de /libs
para /apps
e faça quaisquer alterações em /apps
.