O recurso Estrutura de personalização foi projetado para ajudar a reduzir as violações em áreas não extensíveis do código (como APIS) ou conteúdo (como sobreposições), que não são amigáveis para atualização.
Há dois componentes da estrutura de personalização: a variável Superfície da API e a variável Classificação de conteúdo.
Em versões anteriores do AEM, muitas APIs foram expostas por meio do Uber Jar. Algumas dessas APIs não eram destinadas a serem usadas por clientes, mas foram expostas à funcionalidade AEM compatível em pacotes. Além disso, as APIs do Java serão marcadas como Públicas ou Privadas para indicar aos clientes quais APIs são seguras para usar no contexto de atualizações. Outras especificidades incluem:
APIs Java marcadas como Public
podem ser usados e referenciados por pacotes de implementação personalizados.
As APIs públicas serão compatíveis com a instalação de um pacote de compatibilidade.
O pacote de compatibilidade conterá uma compatibilidade Uber JAR para garantir a compatibilidade com versões anteriores
APIs Java marcadas como Private
destinam-se a ser usados apenas por pacotes internos AEM e não devem ser usados por pacotes personalizados.
O conceito de Private
e Public
neste contexto, não devem ser confundidas com noções Java de classes públicas e privadas.
O AEM há muito tempo usa o principal das sobreposições e do Sling Resource Merger para permitir que os clientes estendam e personalizem a funcionalidade do AEM. Funcionalidade predefinida na qual os consoles e a interface do usuário do AEM são armazenados /libs. Os clientes nunca devem modificar nada abaixo de /libs mas pode adicionar conteúdo adicional abaixo de /apps para sobrepor e estender a funcionalidade definida em /libs (Consulte Desenvolvimento com sobreposições para obter mais informações). Isso ainda causava vários problemas ao atualizar o AEM como o conteúdo no /libs pode mudar, fazendo com que a funcionalidade de sobreposição seja interrompida de maneiras inesperadas. Os clientes também podem estender os componentes do AEM por meio da herança via sling:resourceSuperType
ou simplesmente referenciar um componente no /libs diretamente via sling:resourceType. Problemas de atualização semelhantes podem ocorrer com casos de uso de referência e substituição.
Para tornar mais seguro e fácil para os clientes compreenderem quais as áreas de /libs são seguros para usar e sobrepor o conteúdo no /libs foi classificado com as seguintes misturas:
Público (granite:PublicArea) - Define um nó como público para que ele possa ser sobreposto, herdado ( sling:resourceSuperType
) ou utilizados diretamente ( sling:resourceType
). É seguro atualizar os nós abaixo de /libs marcados como Public com a adição de um pacote de compatibilidade. Em geral, os clientes devem utilizar somente os nós marcados como Públicos.
Abstrato (granito:AbstractArea) - Define um nó como abstrato. Os nós podem ser sobrepostos ou herdados ( sling:resourceSupertype
), mas não deve ser utilizado diretamente ( sling:resourceType
).
Final (granite:FinalArea) - Define um nó como final. Idealmente, os nós classificados como finais não devem ser sobrepostos ou herdados. Os nós finais podem ser usados diretamente via sling:resourceType
. Os subnós no nó final são considerados internos por padrão.
Interno (granite:InternalArea) *- *Define um nó como interno. Os nós classificados como internos idealmente não devem ser sobrepostos, herdados ou usados diretamente. Esses nós se destinam apenas à funcionalidade interna do AEM
Sem Anotação - Os nós herdam a classificação com base na hierarquia de árvore. A raiz / é, por padrão, pública. Os nós com um pai classificado como Interno ou Final também devem ser tratados como Internos.
Essas políticas só são aplicadas em relação aos mecanismos baseados no caminho de pesquisa do Sling. Outras áreas de /libs como uma biblioteca do lado do cliente pode ser marcada como Internal
, mas ainda pode ser usado com a inclusão padrão clientlib. É importante que um cliente continue a respeitar a classificação Interna nesses casos.
Os mixins aplicados no CRXDE Lite mostrarão nós de conteúdo e árvores marcados como INTERNAL
como acinzentado. Para FINAL
somente o ícone fica esmaecido. Os filhos desses nós também aparecerão em cinza. A funcionalidade Sobrepor nó está desativada em ambos os casos.
Público
Final
Interno
Verificação de integridade do conteúdo
A partir do AEM 6.5, o Adobe recomenda o uso do Detector de padrões para detectar violações de acesso ao conteúdo. Os relatórios do detector de padrões são mais detalhados, detectam mais problemas e reduzem a probabilidade de falsos positivos.
Para obter mais informações, consulte Avaliando a complexidade da atualização com o Detector de padrões.
O AEM 6.5 será enviado com uma verificação de integridade para alertar os clientes se um conteúdo sobreposto ou referenciado for usado de forma inconsistente com a classificação do conteúdo.
A Verificação de acesso de conteúdo do Sling/Granite é uma nova verificação de integridade que monitora o repositório para ver se o código do cliente está acessando incorretamente os nós protegidos no AEM.
Isso fará a varredura /apps e normalmente leva vários segundos para ser concluída.
Para acessar essa nova verificação de integridade, é necessário fazer o seguinte:
Na tela inicial do AEM, navegue até Ferramentas > Operações > Relatórios de Integridade
Clique no link Verificação de acesso ao conteúdo do Sling/Granite conforme mostrado abaixo:
Após a conclusão da verificação, uma lista de avisos será exibida notificando um usuário final sobre o nó protegido que está sendo referenciado incorretamente:
Após corrigir as violações, ele retornará ao estado verde:
A verificação de integridade exibe informações coletadas por um serviço em segundo plano que verifica de forma assíncrona sempre que uma sobreposição ou tipo de recurso é usado em todos os caminhos de pesquisa do Sling. Se os mixins de conteúdo forem usados incorretamente, será relatada uma violação.