Як вирішити цей конфлікт між двома модулями функцій?


16

У мене є два типи вмісту з різними меню, переглядами, меню тощо, які я спакував у вигляді двох спеціальних модулів. Обидва типи вмісту використовують таксономію та використовують декілька однакових полів у базі даних. Коли я завантажую ці модулі функцій на новий сайт, вони показують конфлікти один з одним за цими загальними полями та словником, і я не впевнений, що було б найкращим способом вирішити конфлікт.

Хоча модулі Feature призначені для спільної роботи, вони не повинні бути присутніми на одному веб-сайті. Кожен може також працювати і з іншими різними функціями. Вони обидва використовують таксономію та поля для фільтрації подань тощо, тому має сенс, що кожен з них включає ці компоненти у своє визначення функції. Повинен я:

  • Видаліть поля та систематику з одного з модулів та оголосіть залежність від іншого? Це не бажано, оскільки кожен може працювати без іншого.
  • Створіть дві версії функцій, одну для самостійного використання та одну для співпраці.
  • Визначте поля та систематику як окрему особливість?
  • Ігнорувати конфлікт та вмикати модулі? (Якщо я це зробити, вони обидва поділять поле?)
  • Ще одне рішення?

Я ще цього не перевіряв, але чи вимкнення або видалення одного з двох модулів функцій видалить поля з бази даних, навіть якщо цього вимагає інший модуль?

Відповіді:


16

Створіть третю функцію, визначаючи компоненти (*), які використовуються двома іншими незалежними функціями.

В інших двох функціях видаліть компоненти, на які зараз заявлена ​​третя функція, і замість цього перерахуйте третю функцію як залежність.

echo 'digraph G {label = "Графік залежності";  структурний [label = "Структурна особливість \ n (поля, систематика)"];  "Особливість A \ n (тип вмісту)" -> структурна;  "Особливість B \ n (тип вмісту)" -> структурна;  }; '  |  dot -Tpng> залежність.png

(*) У функціях для Drupal 7, однак ця функція ще не задіяна - див. Http://drupal.org/node/1064472 та допоможіть переглянути запропонований код там. - Цей патч був докладений до особливостей 7.x-2.x.


1
Так, це, безумовно, спрацює. Хоча якщо це те, що Особливості змушує користувачів робити, це неелегантне рішення. Особливості забезпечують можливість упаковки функції, а потім не дозволяють нам зробити це повністю. Спільні поля між окремими модулями функцій не повинні бути проблемою. Спасибі
Ешлар

3
@Ashlar: Але що робити, якщо визначення полів у кожній з перших двох особливостей відрізняються - як би вирішити суперечливі визначення? Також загалом проблематично мати декілька авторитетних визначень однієї інформації . Спільний доступ до полів не є проблемою, але проблема з кількома повноваженнями, які визначають, що це за поля.
smokris

2
Ні, я кажу, що вам слід визначити поле один раз (і, таким чином, визначити можливі значення поля один раз ) у структурній функції - і посилатись на це поле у ​​кожному з типів вмісту. (Ак ... Я щойно зрозумів, що те, що я запропонував, передбачає, що патч на drupal.org/node/1064472 застосовано, про що я забув згадати. Відредагована відповідь.)
smokris

1
Спасибі смокріс. Посилання було дуже корисним. У мене було неправильне припущення про те, як керується полем / екземпляром. Ваша відповідь зараз має сенс для мене, і посилання на пластир врятує мене від виривання волосся :)
Ешляр

1
Зазначений патч для D7 Особливості тепер прихильний DEV drupal.org/node/1064472#comment-7235792
danbohea

1

Це рішення на мене справді працювало чудово, набагато надійніший для експорту на різні сайти, ніж створення третьої функції, яка створювала б осиротілі поля на іншому спорідненому сайті.

http://drupal.org/node/1698290


0

Одне з моїх рішень було приєднати дві особливості до однієї більшої риси. Це вирішило конфлікти.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.