Como resolvo esse conflito entre dois módulos de recursos?

Eu tenho dois tipos de conteúdo com vários menus, visualizações, menus, etc., que eu empacotamos como dois módulos personalizados de recursos. Os dois tipos de conteúdo usam taxonomia e usam vários dos mesmos campos no banco de dados. Quando carrego esses módulos de recursos em um novo site, eles mostram conflitos entre si nesses campos e vocabulário comuns e não tenho certeza de qual seria a melhor maneira de resolver o conflito.

Embora os módulos de recursos tenham a intenção de trabalhar juntos, eles não precisam estar presentes no mesmo site. Cada um também pode funcionar com outros recursos diferentes. Ambos usam a taxonomia e os campos para filtrar visualizações etc., portanto, faz sentido que cada um inclua esses componentes na definição de recursos. Eu devo:

Remover os campos e a taxonomia de um dos módulos e declarar uma dependência para o outro? Isso não é desejável, pois cada um pode funcionar sem o outro.
Faça duas versões dos recursos, uma para uso independente e outra para colaboração.
Definir os campos e a taxonomia como um recurso separado?
Ignorar o conflito e ativar os módulos? (Se sim, ambos compartilharão o campo?)
Outra solução?

Ainda não testei isso, mas desabilitar ou desinstalar um dos dois módulos de Recursos removerá os campos do banco de dados, mesmo que o outro módulo exija?

features

— Ashlar
fonte

Respostas:

Crie um terceiro recurso que defina os componentes (*) usados pelos outros dois recursos independentes.

Nos outros dois recursos, remova os componentes que agora são reivindicados pelo terceiro recurso e, em vez disso, liste o terceiro recurso como uma dependência.

$echo 'digraph G {label = "Gráfico de Dependências"; estrutural [label = "Característica Estrutural \ n (Campos, Taxonomia)"]; "Recurso A \ n (Tipo de Conteúdo)" -> estrutural; "Recurso B \ n (tipo de conteúdo)" -> estrutural; }; ' | dot -Tpng> dependency.png$

(*) ~~Nos Recursos do Drupal 7, no entanto, essa funcionalidade ainda não foi confirmada - consulte http://drupal.org/node/1064472 e ajude a revisar o código proposto lá.~~ - Este patch foi comprometido com os Recursos 7.x-2.x.

— smokris
fonte

Sim, isso certamente funcionaria. Embora, se é isso o que o Feature force os usuários a fazer, seja uma solução deselegante. O recurso oferece a capacidade de empacotar um recurso e, em seguida, não nos permite fazê-lo completamente. Campos compartilhados entre módulos de recursos separados não devem ser um problema. Obrigado

— Ashlar

@ Ashlar: Mas e se as definições dos Campos em cada um dos dois primeiros Recursos diferirem - como as definições conflitantes serão resolvidas? Além disso, em geral, ter várias definições autorizadas da mesma informação é problemático . Compartilhar campos não é um problema, mas ter várias autoridades especificando o que são esses campos é um problema.

— 21712 smokris

Não, estou dizendo que você deve definir o campo uma vez (e, assim, definir os possíveis valores do campo uma vez ) no recurso estrutural - e fazer referência a esse campo em cada um dos tipos de conteúdo Features. (ACK ... Eu só percebi que o que eu proposto assume o patch em drupal.org/node/1064472 foi aplicado, que eu esqueci de mencionar resposta editado..)

— smokris

Obrigado smokris. O link foi muito útil. Eu tinha uma suposição errada sobre como o campo / instância foi tratado. A sua resposta agora faz sentido para mim, e o link para o patch irá me salvar de que retira o cabelo :)

— Ashlar

O patch mencionado para D7 Características agora tem sido comprometida com dev drupal.org/node/1064472#comment-7235792

— danbohea

Essa solução funcionou muito bem para mim, muito mais robusta para ser exportada para vários sites do que criar um terceiro recurso, que criaria campos órfãos em outro site não relacionado.

http://drupal.org/node/1698290

— frazras
fonte

Uma solução que funcionou para mim foi anexar os dois Recursos em um recurso maior. Isso resolveu os conflitos.

— sokratis
fonte