Com o status D8 atual, qual é a árvore de decisão para criar um novo tipo de entidade de conteúdo versus criar um Tipo de Conteúdo para a entidade de conteúdo "Nó"?

Vimos quatro anos e o primeiro lançamento do Drupal 8 desde que a resposta aceita foi escrita para a pergunta " Quando é apropriado criar uma Entidade versus apenas adicionar um novo tipo de conteúdo ?" E, as entidades são mais centrais no Drupal 8 do que no Drupal 7. ( RefB , RefC , RefD )

Nesse novo mundo do Drupal 8, qual é a árvore de decisão para criar um novo tipo de entidade de conteúdo versus um novo Tipo de Conteúdo para a entidade de conteúdo do tipo "Nó"?

Ao considerar uma resposta, considere o seguinte:

• Um novo Tipo de Conteúdo para o tipo de entidade de conteúdo de "Nó" ainda é apropriado em situações de 99% versus um novo tipo de entidade de conteúdo?
• A árvore de decisão agora inclui motivos mais, melhores ou mais claros para evitar o uso do tipo de entidade de conteúdo "Nó" e criar um novo tipo de entidade de conteúdo? E se sim, o que são? Eles incluem:
  • Atuação?
  • Segurança / permissões?
  • O número de módulos que funcionam com tipos de conteúdo do tipo entidade de nó e não funcionam com outros tipos de entidade de conteúdo?
• Talvez - com base na resposta aceita anteriormente mencionada acima - a única razão geral para criar um tipo de entidade de conteúdo personalizado seja se você deseja agrupar dados do Nó, por exemplo, com termos de taxonomia, ou anotar Nó, por exemplo, com comentários?

A compatibilidade do módulo parece ser uma consideração particularmente interessante para uma árvore de decisão. No momento, poucos dos módulos mais instalados possuem uma versão 8.x que não é meramente alfa, beta ou rc (uma candidata a versão). E parece difícil identificar quantos deles funcionarão prontos para uso com um novo tipo de entidade personalizado versus um novo tipo de conteúdo da entidade Nó. Não parece haver um atributo de projeto para distinguir entre aqueles "gravados para entidades" versus "gravados para tipos de conteúdo de entidade do nó".

Dê uma olhada no pathauto, que atualmente é o quarto módulo mais instalado daqueles que possuem qualquer tipo de versão 8.x. O pessoal está trabalhando duro em uma versão 8.x que geralmente oferece suporte a entidades e não apenas a Tipos de conteúdo do tipo entidade de nó. Mas e todos os outros módulos? E os módulos que oferecem suporte a entidades que geralmente exigem que os tipos de entidade de conteúdo personalizado tenham "ganchos" específicos ao módulo antes que o módulo funcione com eles? (Versus como os módulos podem funcionar imediatamente com novos tipos de conteúdo?) Esse parece ser o tipo de desafio com o qual a equipe pathauto está trabalhando, e talvez seja um motivo para se afastar de um tipo de entidade de conteúdo personalizado?

Também vale a pena mencionar que o núcleo do Drupal 8 contém uma interface do usuário para criar novos tipos de conteúdo para a entidade de conteúdo do tipo "Nó", mas atualmente não contém uma interface do usuário para criar novos tipos de entidade de conteúdo. ( RefX , RefY , RefZ )

Árvore de decisão para escolher entre criar um novo Tipo de Conteúdo do tipo entidade de nó versus um novo tipo de entidade de conteúdo:

1. Você é um programador ou tem acesso fácil a um programador?
   • Se não, atualmente você está praticamente limitado à criação de novos tipos de conteúdo de entidade do nó. (Não existe uma interface do usuário no núcleo para criar novos tipos de entidade de conteúdo, e o módulo de contribuição do kit de construção de entidades (ECK) atualmente possui apenas uma versão alfa.)
   • Se sim, continue ...
2. Você sabe exatamente quais módulos de contribuição você deseja alavancar para seus dados?
   • Se não, então a aposta segura é provavelmente apenas criar um Tipo de Conteúdo da entidade do nó.
   • Se sim, esses módulos já são compatíveis com o (s) tipo (s) de entidade personalizada que você está considerando ou deseja ajudá-lo (a) a aprimorá-lo para que ele recrie a funcionalidade desejada em seu módulo?
     • Se não, apenas criar um tipo de conteúdo do tipo entidade de nó pode ser melhor para você.
     • Se sim, continue ...
3. Os dados de conteúdo reais habilitados pelo seu módulo ajudarão a agrupar ou anotar outros dados de conteúdo? (Para que raramente seja visto por si próprio.)
   • Se sim, considere se seu módulo é como os tipos de entidade existentes para termos e comentários de taxonomia. Se for, um novo tipo de entidade pode ser uma aposta segura.
   • Se não, continue ...
4. Você pode articular claramente por que um novo tipo de conteúdo do tipo entidade de nó não funcionará para você?
   • Se não, sua aposta segura é provavelmente criar apenas um novo Tipo de Conteúdo do tipo entidade de nó.
   • Se sim, continue ...
5. Por fim, você tem certeza de que não pode apenas estender o tipo de entidade Node e deseja recriar todas as suas funcionalidades úteis, como operações CRUD?
   • Se sim, vá em frente e crie um novo tipo de entidade personalizada.
   • Se não, ou se você não tiver certeza, provavelmente desejará contratar alguns especialistas para ajudá-lo a decidir.

Notas:

1. Essa árvore de decisão não considera desempenho ou segurança. Não tenho certeza se ou quando um novo tipo de entidade de conteúdo personalizado teria melhor desempenho e seria mais ou menos seguro do que um tipo de entidade do Nó.
2. Mesmo que essa árvore seja uma boa resposta, provavelmente não permanecerá uma ao longo do tempo devido a atualizações nas versões do núcleo e do módulo de contribuição do Drupal. O StackExchange não parece acomodar como a resposta "melhor" hoje pode não ser a melhor resposta amanhã.)

Uma abordagem simples sobre esse problema é levar em consideração a finalidade do projeto, tamanho e requisitos de negócios.

1. Como o tipo de conteúdo padrão da entidade do nó afeta a construção do projeto de maneira fácil e organizada, mais próxima da arquitetura e dos fluxos de dados produzidos a partir do pensamento analítico dos documentos do projeto.

Um aviso importante aqui é a decisão de criar um novo tipo de entidade geralmente tomada por desenvolvedores ou líderes técnicos, não por construtores de sites ou proprietários de projetos que gerenciam o aplicativo e se concentram apenas nos negócios.

2. O Drupal 8 depende de alguns pacotes do symfony2 e é mais próximo dos frameworks, o desenvolvimento que os cms tradicionais falam sobre o Drupal com essas grandes mudanças arquiteturais, imagino que construir uma nova entidade é melhor do que fazer muitas customizações e configurações complexas sobre os tipos de conteúdo das entidades dos nós. Para alavancar o Drupal entre outras estruturas, como muitas pessoas não gostam da maneira como as configurações e as configurações distribuídas do Drupal, você pode enfrentar algumas pessoas que vêm do WordPress e costumavam configurar tudo de uma forma que as irrita ao lidar com o painel de administração do Drupal.

3. O Drupal 9 planeja remover totalmente o sistema de ganchos e substituí-lo pelo despachante de eventos, o que leva a uma grande necessidade de uma interface administrativa para criar uma nova entidade, pois alterar a funcionalidade existente do código será muito mais difícil para as pessoas que não são desenvolvedores e será essencial para adicione esse recurso.

No final , vejo que novas entidades personalizadas para as necessidades do projeto oferecem alto desempenho melhor do que tipos de conteúdo complexos, com grande número de campos, pois agora cada campo adiciona 2 tabelas ao banco de dados e precisa carregar sua configuração em cada solicitação, especialmente com o é necessária uma lógica comercial pesada.

Puro e simples: nem tudo é conteúdo. A lista do conteúdo pode demorar bastante e ser confusa se você estiver apenas usando tipos de conteúdo. ( ContentEntityBase também pode ser implementado por uma entidade personalizada thoe)

Se você tem um autor e um estado publicado, deve procurar um tipo de conteúdo.

Caso contrário (supondo que você seja um programador), as entidades personalizadas devem ser preferidas. Muito pode ser facilmente implementado com todas as interfaces (como capacidade de revisão, capacidade de campo, restrição de acesso etc.)

Na minha opinião, isso é apenas uma arquitetura mais clara e ordenada pela cauda (e também com mais desempenho).

Pensando em reutilização em vários projetos, o esforço para fazer explodir as entidades personalizadas ... também existem ajudantes bacanas, como o gerador de código drupal . Para manter a codificação (ou complexidade) personalizada em um nível baixo, considere o uso de tipos de conteúdo, se desejar:

• Para traduzir a 'entidade' (pelo menos em D7), haveria também uma interface.
• (aberto para sugestões) ..

É uma pergunta difícil que, honestamente, acho que só é compreendida depois que você a implementou antes. Mas como remy mencionou, nem tudo é cru, conteúdo voltado para o usuário .

No Drupal 7, a capacidade de criar entidades personalizadas existia, mas poderia ser uma tarefa assustadora, se você tivesse dificuldades com o OOP. Foi meio que implementado (ou meio pronto, como você quiser dizer), o que levou a maneiras de criar entidades que não eram exatamente uniformes e com abordagens acordadas, com procedimentos mistos e procedimentos opostos.

No Drupal 8, a ideia é muito mais realizada e é muito mais fácil começar a operar com uma entidade personalizada. O nó em si é baseado em ContentEntityBase, assim como Blocos, Usuários, Arquivo e Taxonomia.

Os nós são especificamente para dados de conteúdo publicados, visíveis (ou autorizados) que normalmente atuam como conteúdo (ou seja, em um menu ou no mapa do site, no mapa do site xml ou nos feeds RSS, etc.). O Drupal foi projetado de uma maneira em que você pode conectar-se a qualquer etapa do processo de operações do nó e alterá-lo, o que pode ter consequências indesejadas se você tiver a combinação errada de módulos contribuídos. Essa é provavelmente uma opinião controversa, mas ajuda a se divorciar da ideia de "tudo é um nó" para abraçar mais o conceito de entidade.

Conteúdo ideal que cria ótimos tipos de conteúdo:

• Artigo
• Página
• Anúncio de emprego
• Evento
• Página de destino
• Pagina inicial

O ponto comum a eles é que eles compartilham o conceito de um tipo de conteúdo. Geralmente está em vários estados do fluxo de trabalho (publicado, promovido, persistente, arquivado, em destaque etc.), se você usar opções de publicação personalizadas, e um grande número de módulos contribuídos interage diretamente com ele, como o Pathauto.

Mas vamos supor que você queira armazenar dados no Drupal que sejam internos, privados, gerem outros dados ou dados que não devem permitir a integração fora de seu escopo, a menos que você permita. Que tipo de dados podem ser esses? Aqui estão alguns tipos possíveis:

• Produto (Drupal Commerce)
• Item de linha (Drupal Commerce)
• Servidor de pesquisa (ApacheSolr / SearchAPI)
• Contato (como líder de CRM)
• Ticket (como ticket de suporte)

O que os torna tão diferentes? Por que você deseja uma entidade para contato, em vez de usar o modelo de usuário? Você pode argumentar aqui, mas meu exemplo seria que, se você disser, coletando endereços de email, nomes e alguns outros metadados de um formulário de contato, armazene esses dados como uma entidade personalizada. Você evita que a lista de usuários seja poluída com itens que não são da conta, reduz possíveis problemas de segurança (e se um script ou alguém atualiza acidentalmente essas contas para serem administradores ou envia um email em massa?), Você faz um gerenciamento de sobrecarga interno do usuário real contas mais fáceis e você segmenta o que você está capturando para o que é, uma parte especializada de dados.

A partir daqui, ela é amplamente separada das partes mais automáticas do sistema Drupal / Node e você pode personalizar as ações e a experiência. Você determina as rotas, o acesso e o fluxo de trabalho CRUD.

Nessa mentalidade, fica mais fácil ver por que a abordagem seria feita dessa maneira. Veja o exemplo do tíquete de suporte - trata-se de solicitações recebidas, mas não de dados publicados, e provavelmente possui um fluxo de trabalho muito específico que é mais fácil de configurar do que separá-lo de partes do sistema de nós que você não deseja aderir. para.

Outro exemplo seria dados importados externos. Na maioria dos casos, esses dados geralmente não são enriquecidos com os dados locais do Drupal (mesmo que, como entidade, você ainda possa fazê-lo). Poderia ser qualquer coisa. Talvez sejam faturas, talvez livros, talvez esteja puxando marcas de cerveja.

Dados como esse geralmente são específicos e requerem controle além do objetivo do nó. Isso não quer dizer que você não possa aumentá-lo usando um campo de referência em um nó para apontar para sua entidade personalizada (é assim que o Drupal Commerce trabalhou, em algum nível) para enriquecer os dados. Ao mesmo tempo, você está isolando e garantindo controle sobre seus dados e interface do usuário do código de contribuição incorreto, indo além do design e interferindo no seu modelo. Provavelmente, isso é menos problemático no D8 do que no D7, embora alguns ganchos permaneçam.

A arquitetura adequada agora existe para incentivar a separação. Nem tudo é um nó.