Quais são as vantagens ou desvantagens do uso de módulos baseados em referência em vez do módulo de taxonomia?


9

Gostaria de saber como decidir usar o módulo principal de taxonomia ou o módulo de referência de entidade ?

Eu não usei o módulo Referência de entidades antes, mas usei o módulo de taxonomia (e alguns módulos relacionados) em 10 a 15 sites.

Quais são as vantagens ou desvantagens do uso de módulos baseados em referência em vez do módulo de taxonomia?


Recentemente, comecei a construir um site de arquivos de revistas.

Existem muitas revistas. Essas revistas têm problemas. Cada edição tem artigos.


A menor (e mais profunda) parte aqui são os artigos .

Artigo

  • Número da página (intervalo):
  • Título:
  • Autor:
  • Tipo de artigo:
  • Palavras-chave:
  • Revista:
  • Questão:


Questão

  • Numero da edição:
  • Imagem de capa:
  • Data de publicação):
  • Revista:


Revista

  • Descrição:
  • Imagem de capa:


insira a descrição da imagem aqui

Aqui, existem (pelo menos) 2 métodos para implementar este site:

1. Haverá um tipo de conteúdo chamado articlee todos os outros (edição, revista, autor) serão termos de taxonomia (hierárquicos). Haveria uma hierarquia entre edição e revista, etc.

2. Haverá muitos tipos de conteúdo: artigo, edição, revista, autor. Ao criar artigos; edição, revista e autor podem ser referenciados etc.

Então, teoricamente, os dois lados parecem muito semelhantes.

Existe alguém que enfrentou uma situação semelhante e você poderia dizer qual o método preferido, por quê?

Respostas:


9

Existem também outras soluções para o seu problema.

Coleção Field

Você pode usar coleta de campo e coleta de campo de vistas de módulos para armazenar e organizar conteúdo. Usando essa abordagem, o Issuee Magazinevai ser do tipo Coleta de Campo, Issueé um campo de Articlee Magazineé um campo de Issue. Tenho experiência em implementar essa estrutura. No meu caso, o requisito era um Libraryque deveria conter livros (com campos Título, Editor e ...). Todo livro contém vários volumes (Número de páginas, tradutor, ...) e cada volume também contém um número ilimitado de outros itens. (como a digitalização de algumas páginas que não são iguais entre os livros).

Eu implementei isso usando a abordagem Field Collection e é muito bom. Você pode criar facilmente um link para editar todos os itens individuais de cada coleção de campos e também pode filtrar por itens da coleção de campos. Postei uma resposta para Agrupar itens nas Visualizações por valor na Coleção de Campos, que mostra como trabalhar com as Visualizações de Coleção de Campos.

Anexo de exibição de entidade

Também conhecido como módulo EVA .

"Eva" é a abreviação de "Anexo de exibições de entidade"; ele fornece um plug-in de exibição de Views que permite que a saída de uma View seja anexada ao conteúdo de qualquer entidade Drupal. O corpo de um nó ou comentário, o perfil de uma conta de usuário ou a página de listagem para um termo de Taxonomia são exemplos de conteúdo da entidade.

Você pode usar o EVA para exibir apenas valores de campos para uma parte específica do conteúdo, oferecendo um controle incrível sobre a exibição e a flexibilidade de formatação dos campos. Por exemplo, você pode desejar ter dois campos concatenados de alguma maneira especial. Você pode adicionar seus campos à exibição do EVA, definir o filtro contextual como NID, adicionar um campo Global: texto e, usando tokens, formatar seus campos com HTML. Não se esqueça de excluir seus campos da exibição se for usá-los juntos em um campo Global: texto. Exemplo: você pode ter uma cidade, estado e campos de CEP. Você pode combiná-los em um campo Global: Texto nas exibições para exibir como "Cidade, CEP do estado". Quando você gerencia a exibição do seu tipo de conteúdo, adicione o EVA recém-criado à exibição e, sempre que um nó for exibido, ele passará seu nid para o EVA, e o EVA retornará os campos selecionados, formatado como você deseja. (fonte :Como fazer do caso de uso de referência do EVA e da entidade )

Este módulo é perfeito, anexa uma visualização como um campo aos nós de um tipo de conteúdo. Eu usei este módulo para criar um Album. O álbum contém singer(com algumas informações sobre cada um) e songscontém um arquivo, título, taxa e .... Então, criei uma visualização do tipo EVA e a anexei a um nó. Então, na página do nó de todo cantor, eu mostrei essa Visualização, que obtém as informações apropriadas do nó. O Views com referência de entidade é um tutorial perfeito de como usar este módulo.

Termos de taxonomia VS Referência da entidade

Eu recomendo que você leia Referência da entidade versus taxonomia e há algum benefício / advertência ao usar a Referência da entidade sobre a Referência de termos? , Como diz as taxonomias, é melhor usar ao organizar itens semelhantes de maneira hierárquica. Como tags .

A taxonomia permite que você use a codificação gratuita (pode ser desativada usando o módulo Taxonomia de conteúdo ), o que permite a criação de novas tags em tempo real. É muito fácil modificar o esqueleto do conteúdo. Usando essa abordagem, usuários regulares ou pelo menos alguns usuários autenticados (que não têm conhecimento de programação) podem mudar esse esqueleto. O módulo Hierarchical Select é um exemplo perfeito dessa abordagem.

Embora a taxonomia seja fácil de usar, mas eu prefiro a Referência de entidade, ela abre muitas possibilidades e escalabilidade e permite a criação de estruturas muito complexas. O conceito de entidade neste contexto não se limita ao conteúdo. Podem ser comentários, usuários, taxonomias e .... É muito mais escalável, para que você não se preocupe com a personalização de tipos de conteúdo ou com a modificação no futuro (como indicado na referência da entidade versus taxonomia ). Eu acredito que a abordagem da entidade é mais poderosa que a taxonomia.

Existem também outras combinações dessas abordagens, das quais não é necessário mencioná-las.

De qualquer forma, recomendo que você entenda completamente a abordagem de entidade e seus módulos relacionados. Se você o usar em vários projetos, apesar da complexidade, será muito fácil usá-lo. Não apenas no seu requisito atual, mas também no futuro, será uma ferramenta muito confiável para você.


Muito obrigado pela sua resposta detalhada. Isso me deu uma boa perspectiva sobre o uso de módulos não taxonômicos. Há duas coisas a entender antes de usar esse tipo de solução: 1. A taxonomia possui o recurso de preenchimento automático. Esses módulos possuem esse recurso? Como, sem o recurso de preenchimento automático no nó, é quase impossível criar um site. 2. Posso usar o próprio módulo principal de taxonomia sem outros módulos, mas as soluções mencionadas precisam de alguns módulos extras extras e é difícil saber "usar quais outros módulos seriam bons" . Obrigado novamente.
Herci

2
Bem vindo. Sobre a pergunta número 1, se você usar o módulo Entidade e o campo de referência da entidade, sim, ele será preenchido automaticamente. Se você usar o Field Collection, ele não precisará ser preenchido automaticamente porque não faz nenhum relacionamento, o nó e seus filhos são encapsulados como um pacote único. Sobre a pergunta 2, Muitos módulos dependem do módulo Entity; portanto, não importa qual abordagem você esteja usando, será necessário instalar e ativar esse módulo. Furtheremore Eu acho que o poder que fornece-lhe merece a instalação de algumas módulos
M ama D

Embora eu recomende ficar longe das coleções de campo, a entidade com campos de referência de entidade é uma ferramenta excelente e muito poderosa. Combinado com algo como CER (Referências a entidades correspondentes), você obtém relacionamentos bidirecionais; portanto, no seu caso, o artigo saberá a qual edição e revista pertence, juntamente com a questão que conhece o artigo. Devo observar que as visualizações já têm uma pesquisa inversa para os relacionamentos de entidade, mas isso é mais rápido e abre novas possibilidades.
Mediaashley

11
@ mediaashley para obter um relacionamento de duas maneiras, não é necessário instalar o CER. Usando relacionamentos, você pode conseguir isso facilmente. O drupal.stackexchange.com/questions/124893/… explica isso
M ama D

2
Eu recomendaria ficar longe das coleções de campos para outros casos que não sejam simples. Ao lidar com requisitos mais complexos, você encontrará que, a longo prazo, as coleções de campo são pouco suportadas em outros módulos. Outro problema é que todas as técnicas drupal para acessar e manipular dados aos quais você se acostumou não se aplicam aos dados armazenados nas coleções de campos. É claro que ainda é possível fazer toda a manipulação de dados, no entanto, a implementação é bastante confusa. Vá com a referência da entidade.
gbyte.co

8

Você também pode ter alguma outra combinação, como artigos e edições são nós e revistas são taxonomias.

Não há realmente uma resposta certa ou errada para isso, ela se resume a preferências pessoais, requisitos específicos do projeto etc.

É melhor usar nós para conteúdo e taxonomias para categorizar esse conteúdo; no entanto, às vezes, pode ficar um pouco obscuro se algo é apenas categorização ou seu próprio conteúdo.

Por exemplo, seus campos de tipo de artigo e palavras-chave parecem ser obviamente mais taxonomias, mas edições e revistas podem realmente ser de qualquer maneira.

Uma coisa que pode influenciar sua decisão é a funcionalidade pronta para uso. Por exemplo, há muito mais módulos complementares para nós do que para taxonomias, mas para taxonomias você sai das páginas de listagem da caixa (se desejar). Também pode haver funcionalidade relacionada à hierarquia que é mais fácil de sair da caixa com uma solução ou outra.

As definições de tipo de conteúdo são apenas parte da imagem. Definitivamente, você deve considerar completamente como pretende que o conteúdo seja apresentado ao usuário, como deseja que ele navegue pela hierarquia de conteúdo, como esse conteúdo se relaciona com outro conteúdo do site, como deseja que os administradores administrem esse conteúdo. conteúdo, etc. Por exemplo, você deseja algum tipo de sistema hierárquico de menus, deseja que as pessoas possam ir para páginas de revistas ou edições ou é um conteúdo relacionado àqueles visíveis apenas nas páginas dos artigos. Deseja ter uma única pesquisa que lista todos os três tipos de conteúdo (isso pode ser menos trivial se alguns forem nós e alguns forem termos de taxonomia).

Planeje tudo isso e veja quais módulos estão disponíveis para ajudá-lo a conseguir isso. Você pode encontrar uma maneira de facilitar o alcance do que deseja. Caso contrário, basta seguir o que achar melhor, por qualquer motivo.

Às vezes, você pode seguir um caminho e, em seguida, encontrar algo que dificulta o atendimento de seus requisitos. Se você planeja com antecedência, tanto quanto possível, diminui esse risco.


Sim, você disse que pode haver outra combinação. Vou tentar os módulos baseados em referência, porque já usei as soluções baseadas em taxonomia em muitos projetos. Vou compartilhar os resultados para este caso. Obrigado.
Herci

5

Outra consideração ao usar termos de taxonomia para coisas como "Revista" é que você perderá funcionalidades como revisão e comentários sobre esses itens. As revisões concedidas podem ser adicionadas a um módulo, como a revisão de taxonomia, mas esse é um módulo com uma base de instalação muito baixa. Pessoalmente, eu confiaria que os núcleos da manipulação de revisões nos nós sobre isso.

Posso pensar em pelo menos uma ocasião em que tive que mudar algo de um termo de taxonomia para um nó depois que um projeto foi lançado devido a mudanças nos requisitos, e isso envolve um pouco de reestruturação e migração.

Você provavelmente descobrirá que, se passar a usar outros tipos de entidade, como nós com entity_reference, não terá problemas para fazer a alteração, pois tudo funciona da mesma maneira, mas isso lhe dará mais flexibilidade.


Obrigado, a parte da revisão é um bom ponto. Como você disse, migrar da taxonomia para o nó é difícil. Provavelmente, usarei uma solução baseada em node + entity_reference . Mais uma vez obrigado pela sua resposta.
Herci

3

Não direi que essa é a resposta mais precisa, mas é assim que penso. Vou explicar com alguns exemplos.

Eu costumo usar taxonomias para categorizar nós com base em uma abstração. Por exemplo, as notícias podem ser categorizadas em esporte, política etc.

Mas quando quero ter uma referência como uma revista, estou pensando no futuro. Pense em quando você deseja ajudar o usuário a decidir qual artigo escolher. A classificação da revista (fator de impacto, talvez) é uma possibilidade. Ou talvez eu queira entrar em contato com a revista. Um termo não me ajudaria nessa situação, onde, se fosse um nó ou entidade, o faria.

Por outro lado, você deve fazer algumas coisas sozinho. Por exemplo, clicar em um termo de taxonomia levaria a uma página preenchida com nós categorizados desse termo. Portanto, agora é necessária uma visualização e um filtro contextual etc.


3

Eu tinha certeza de que alguém perguntou por que eu ficaria longe das coleções de campos, mas o comentário parece ter sido removido. De qualquer maneira meus 2 centavos:

As taxonomias devem ser usadas para classificação e categorização. Não para relacionamentos de conteúdo. Ao vincular 2 partes do conteúdo por meio de um termo de taxonomia, você está usando 3 entidades, nas quais você só precisa de 2.

De acordo com minha experiência, embora as taxonomias agora sejam passíveis de campo, elas não são entidades de pleno direito e, portanto, não devem ser usadas como "conteúdo".

Nesse caso específico, se sua revista tiver conteúdo (uma descrição do que é, detalhes sobre como solicitá-la etc.) ou uma "página" própria, ela deverá ser um tipo de conteúdo, porque é conteúdo.

Os problemas são um pouco ambíguos, mas é provável que você tenha uma visão geral, etc., portanto eles provavelmente têm uma página e também o conteúdo. Então, outro tipo de conteúdo.

Os artigos são obviamente tipos de conteúdo.

Ao criar o administrador para isso, você pode usar a Referência da entidade para vincular essas partes do conteúdo, mas pode melhorar ainda mais.

Da mesma maneira que o @Drupalist sugeriu usar Coleções de Campo, você pode usar formulários de entidade em linha (acho que parte da Referência de Entidades). As coleções de campo são um desses módulos antigos que oferecem uma ótima idéia, não muito bem implementada e com muitas colisões com outros módulos. Embora agora sejam entidades, eles ainda têm problemas, e seria melhor usar entidades de pleno direito (até mesmo tipos de conteúdo) para coisas como seus autores etc.

Os formulários de entidade embutidos permitem criar e editar entidades referenciadas, de dentro da entidade da qual você deseja referenciar ... então, crie / edite o autor de dentro de um artigo ou apenas faça referência a um que já foi criado.

Adicione o CER e você receberá automaticamente uma referência do autor de volta ao artigo, do artigo de volta à edição e da edição de volta à Revista, ou qualquer direção que você esteja seguindo. Isso tem vantagens no desempenho de suas visualizações, mas também permite mostrar uma lista de artigos na página do autor e as informações do autor na página do artigo, tudo sem visualizações.

Em um círculo completo de volta às taxonomias, você os usaria para "marcar" artigos etc. com ... "pesca", "carro", "computadores" etc. / qualquer que seja ... para encontrar qualquer problema, revista, artigo ou autor que tenha conteúdo / tenha escrito sobre essa tag.

Tentou fazer isso breve, então espero que ajude e faça sentido. Eu fiz isso em dezenas de sites. Eventos esportivos globais, sites de reservas de viagens / férias, emissoras internacionais, bebidas, instituições de caridade etc. Robusto e potente, e cobre você para necessidades imprevistas.


Obrigado pela sua resposta. Realmente faz sentido e a experiência de leitura é muito importante para mim.
Herci
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.