Qual é o benefício de criar novos tipos de entidade ao invés de criar um novo tipo de conteúdo?
Parece um pouco exagerado executar toda a codificação personalizada necessária para criar uma nova entidade quando você tiver toda a funcionalidade CRUD e Views já incorporada aos tipos de conteúdo.
Respostas:
Não se trata tanto dos benefícios, mas mais do que é apropriado para uma situação específica, como você disse. Você pode representar praticamente qualquer coisa com um nó e, em 99% das situações (como descobri pelo menos), não será necessário implementar tipos de entidade personalizados.
Eu sempre penso no taxonomy_termtipo de entidade como um bom exemplo de por que nem tudo deve ser um tipo de nó / conteúdo:
Um termo de taxonomia é essencialmente para agrupar entidades diferentes e, como tal, não requer a mesma funcionalidade que um nó. Embora você possa teoricamente usar um tipo de conteúdo para executar essa funcionalidade (talvez com um campo de referência de nó), um termo de taxonomia não precisa fazer a mesma coisa que um nó, por isso não faz sentido. O mesmo pode ser dito para os tipos de entidade usere taxonomy_vocabulary.
Portanto, um termo de taxonomia é criado como uma entidade separada e é programado para fazer apenas o que for necessário, enquanto obtém os benefícios de poder ter campos anexados etc.
Eu acho que a resposta simples é que, quando um nó / tipo de conteúdo não faz o que você precisa, ou é apenas uma quantidade enorme de sobrecarga / sobrecarga por muito pouco benefício, você deve optar por escrever uma entidade personalizada.
Isso é baseado apenas na minha experiência pessoal; Eu ficaria interessado em ouvir o que alguém diretamente envolvido com o desenvolvimento do núcleo do Drupal tinha a dizer sobre isso.
Uma regra muito simples que eu uso é se o seu conteúdo precisa ser exibido publicamente por conta própria. Nesse caso, escolha o nó, se não escolher uma entidade. Agora, as Entityforms permitem criar uma interface para preencher suas entidades.
Por exemplo, em um site feito com D6 vamos construir um tipo de anúncio de conteúdo (com o seu campo de imagem, começar / data de exibição final ...), mas então você tem que fazer isso não publicado por padrão e dar a seus editores o direito de editar / visualiza esses nós e espera que nenhuma visualização / pesquisa os exiba no mundo exterior. É bastante complicado e seria mais fácil lidar com entidades.
Uma entidade representa um caso de uso específico .
Acredito que o crédito por essa definição simples vá para o Fago , mas estou com preguiça de encontrar uma referência.
Poderíamos usar Content(aka Nodes) para todos os casos de uso, se quiséssemos, mas muitas vezes isso não faz sentido.
Content possui um autor e configurações para comentários e localização do menu.
Users, representa um caso de uso diferente o suficiente, Contentporque, em usernenhum dos itens acima, faz sentido, enquanto, por outro lado, um userdeve ter um email e uma senha.
Taxonomy terms destacam-se porque possuem a funcionalidade incorporada para ser organizada em uma hierarquia, mesmo circular.
Se o seu caso de uso for semelhante o suficiente a uma entidade existente, continue usando essa entidade. Se sua entidade for governada por regras significativamente diferentes das existentes, crie uma nova.
Há também uma introdução às entidades , mas infelizmente não responde à sua pergunta.
Eu acho que é tudo sobre o contexto, um nó é amplamente usado para conteúdo, de modo que seriam blogs, artigos, perguntas frequentes etc. Enquanto usuário de perfis como funcionários, clientes etc. Exemplo de quando você pode criar uma nova entidade:
Embora você possa usar um nó para algo como um tíquete de suporte, pode não ser o melhor modelo e padrões ... Espero que ajude.
As entidades podem ser criadas com menos sobrecarga do que os nós, pois não precisam ter todas as funcionalidades pesadas que as entidades possuem.
Isso também significa que o armazenamento pode ser mais simples - você pode construí-los para capturar todas as informações em uma consulta simples sem JOINS, se desejar. Todos os campos bem em apenas uma mesa arrumada.
Isso pode ser um grande benefício se você tiver muitas funções que precisam fazer consultas nas entidades e estiver atualizando muitas entidades simultaneamente com as consultas UPDATE no banco de dados. Se você pode garantir que os dados sejam relativamente independentes em uma única tabela, você terá menos preocupações e possibilidades de corrupção de dados.
Um tipo de conteúdo foi projetado para ser o conteúdo do site. Ou seja, cada tipo de conteúdo é projetado para ser publicado e exibido no site. Por exemplo, um artigo (pronto para uso) foi projetado para aparecer na primeira página.
Agora, digamos que você queira criar um formulário de inscrição para emprego ou apartamento. Obviamente, você não gostaria de publicar o pedido de emprego de alguém em seu site. Além disso, e se você quisesse criar uma lista de contatos de clientes / leads? Deseja arriscar que essas informações sejam publicadas por engano em seu site? Pessoalmente, eu não faria.
Portanto, o módulo de formulário da entidade que é discutido acima. Permite criar um tipo de entidade que não foi projetado para ser conteúdo. No entanto, esses tipos de entidade estão disponíveis para qualquer módulo que suporte entidades como regras, visualizações e grupo orgânico, para citar apenas alguns.
E então você entra no Drupal Commerce, onde os produtos são do tipo entidade. Basicamente, as entidades permitem que os desenvolvedores estendam o Drupal de maneira nunca prevista pelos designers originais do Drupal.
Isso está sujeito a discussão e, no final, você precisa tomar suas decisões como desenvolvedor.
Eu escolho entidades sobre nós sempre que os dados não devem estar disponíveis ao público com seu próprio URL. Os nós estão obtendo por padrão um alias de URL, status publicado, um título, meta tags, ... enquanto entidades apenas obtêm um registro no banco de dados.
"Quero poder adicionar o máximo possível de banners com texto e, em seguida, em um post do blog, escolher entre um deles"
Entidade vs Conteúdo
A entidade possui pacotes de entidades que possuem campos
O conteúdo é um tipo de entidade. Assim,
O conteúdo possui bundles de conteúdo (artigo, página) com campos (corpo, imagem do artigo)
Se você é programador, certamente escolhe o caminho para criar sua própria Entidade, mas para os construtores de sites pode não ser o melhor caminho a seguir. Novamente, para os construtores de sites, há uma interface do usuário para a criação da entidade http://drupal.org/project/eck