Comment résoudre ce conflit entre deux modules de fonctionnalités?

16

J'ai deux types de contenu avec différents menus, vues, menus, etc. que j'ai emballés en deux modules personnalisés de fonctionnalités. Les deux types de contenu utilisent à la fois une taxonomie et utilisent plusieurs des mêmes champs dans la base de données. Lorsque je charge ces modules de fonctionnalités dans un nouveau site, ils montrent des conflits entre eux sur ces champs et vocabulaire communs et je ne suis pas certain de la meilleure façon de résoudre le conflit.

Bien que les modules de fonctionnalité soient destinés à fonctionner ensemble, ils n'ont pas besoin d'être tous les deux présents sur le même site. Chacun peut également fonctionner avec d'autres fonctionnalités différentes. Ils utilisent tous deux la taxonomie et les champs pour le filtrage des vues, etc. il est donc logique qu'ils incluent chacun ces composants dans leur définition de fonctionnalité. Devrais-je:

  • Supprimer les champs et la taxonomie de l'un des modules et déclarer une dépendance à l'autre? Ce n'est pas souhaitable car chacun peut fonctionner sans l'autre.
  • Créez deux versions des fonctionnalités, une pour une utilisation indépendante et une pour la collaboration.
  • Définir les champs et la taxonomie comme une fonctionnalité distincte?
  • Ignorer le conflit et activer les modules? (Si je le fais, partageront-ils tous les deux le terrain?)
  • Une autre solution?

Je n'ai pas encore testé cela, mais la désactivation ou la désinstallation de l'un des deux modules de fonctionnalités supprimera-t-elle les champs de la base de données même si l'autre module l'exige?

features Pierre de taille
la source

Réponses:

16

Créez une troisième entité définissant les composants (*) utilisés par les deux autres entités indépendantes.

Dans les deux autres fonctionnalités, supprimez les composants qui sont désormais revendiqués par la troisième fonctionnalité et, à la place, répertoriez la troisième fonctionnalité en tant que dépendance.

echo 'digraph G {label = "Dependency Graph"; structural [label = "Caractéristique structurelle \ n (Champs, Taxonomie)"]; "Fonctionnalité A \ n (Type de contenu)" -> structurelle; "Fonction B \ n (Type de contenu)" -> structurel; }; ' | dot -Tpng> dependency.png

(*) Dans les fonctionnalités de Drupal 7, cependant, cette fonctionnalité n'est pas encore validée - voir http://drupal.org/node/1064472 , et aidez-y à revoir le code proposé. - Ce correctif a été validé pour les fonctionnalités 7.x-2.x.

smokris
la source
1
Ouais, ça marcherait certainement. Bien que si c'est ce que les fonctionnalités obligent les utilisateurs à faire, il s'agit d'une solution inélégante. Les fonctionnalités offrent la possibilité de regrouper une fonctionnalité, puis ne nous permettent pas de le faire complètement. Les champs partagés entre des modules de fonctionnalités distincts ne devraient pas poser de problème. Merci
Ashlar
3
@Ashlar: Mais que se passe-t-il si les définitions des champs dans chacune des deux premières fonctionnalités diffèrent - comment les définitions en conflit seraient-elles résolues? De plus, en général, avoir plusieurs définitions faisant autorité de la même information est problématique . Le partage de champs n'est pas un problème, mais le fait d'avoir plusieurs autorités spécifiant ce que sont ces champs est un problème.
smokris
2
Non, je dis que vous devez définir le champ une fois (et ainsi définir les valeurs possibles du champ une fois ) dans la fonction structurelle - et référencer ce champ dans chacune des fonctionnalités de type de contenu. (Ack ... Je viens de réaliser que ce que j'ai proposé suppose que le patch sur drupal.org/node/1064472 a été appliqué, ce que j'ai oublié de mentionner. Réponse
modifiée
1
Merci smokris. Le lien a été très utile. J'avais une hypothèse erronée sur la façon dont le champ / l'instance était géré. Votre réponse a maintenant un sens pour moi, et le lien vers le patch m'évitera d'arracher les cheveux :)
Ashlar
1
Le correctif mentionné pour les fonctionnalités D7 a maintenant été validé
danbohea
1

Cette solution a très bien fonctionné pour moi, beaucoup plus robuste pour être exportée vers divers sites que la création d'une troisième fonctionnalité, qui créerait des champs orphelins dans un autre site non lié.

http://drupal.org/node/1698290

frazras
la source
0

Une solution qui a fonctionné pour moi a été d'attacher les deux fonctionnalités en une seule plus grande, ce qui a résolu les conflits.

sokratis
la source