¿Cómo resuelvo este conflicto entre dos módulos de funciones?


16

Tengo dos tipos de contenido con varios menús, vistas, menús, etc. que he empaquetado como dos módulos personalizados de características. Los dos tipos de contenido usan una taxonomía y usan varios de los mismos campos en la base de datos. Cuando cargo estos módulos de funciones en un nuevo sitio, muestran conflictos entre ellos sobre estos campos y vocabulario comunes y no estoy seguro de cuál sería la mejor manera de resolver el conflicto.

Aunque los módulos de funciones están diseñados para trabajar juntos, no es necesario que ambos estén presentes en el mismo sitio. Cada uno también puede funcionar con otras características diferentes. Ambos usan la taxonomía y los campos para el filtrado de vistas, etc., por lo que tiene sentido que cada uno incluya estos componentes en su definición de Característica. Debería:

  • ¿Eliminar los campos y la taxonomía de uno de los módulos y declarar una dependencia al otro? Esto no es deseable ya que cada uno puede funcionar sin el otro.
  • Haga dos versiones de las funciones, una para uso independiente y otra para colaborar.
  • ¿Definir los campos y la taxonomía como una característica separada?
  • ¿Ignorar el conflicto y habilitar los módulos? (Si lo hago, ¿compartirán ambos el campo?)
  • ¿Otra solución?

Todavía no he probado esto, pero ¿deshabilitar o desinstalar uno de los dos módulos de características eliminará los campos de la base de datos aunque el otro módulo lo requiera?

Respuestas:


16

Cree una tercera característica que defina los componentes (*) utilizados por las otras dos características independientes.

En las otras dos características, elimine los componentes que ahora reclama la tercera característica y, en su lugar, enumere la tercera característica como una dependencia.

echo 'digraph G {label = "Gráfico de dependencia";  estructural [label = "Característica estructural \ n (Campos, Taxonomía)"];  "Característica A \ n (Tipo de contenido)" -> estructural;  "Característica B \ n (Tipo de contenido)" -> estructural;  }; '  El |  dot -Tpng> dependency.png

(*) Sin embargo, en Funciones para Drupal 7, esta funcionalidad aún no está comprometida; consulte http://drupal.org/node/1064472 y ayude a revisar el código propuesto allí. - Este parche se ha comprometido con las características 7.x-2.x.


1
Sí, eso ciertamente funcionaría. Aunque si eso es lo que Características obliga a los usuarios a hacer, es una solución poco elegante. Las características proporcionan la capacidad de empaquetar una característica, y luego no nos permiten hacerlo por completo. Los campos compartidos entre módulos de funciones separados no deberían ser un problema. Gracias
Ashlar

3
@Ashlar: Pero, ¿qué pasaría si las definiciones de los Campos en cada una de las primeras dos Características difieren? ¿Cómo se resolverían las definiciones en conflicto? Además, en general, tener múltiples definiciones autorizadas de la misma información es problemático . Compartir campos no es un problema, pero tener múltiples autoridades que especifican cuáles son esos campos es un problema.
smokris

2
No, estoy diciendo que debe definir el campo una vez (y, por lo tanto, definir los valores posibles del campo una vez ) en la característica estructural, y hacer referencia a ese campo en cada una de las características del tipo de contenido. (Ack ... Me acabo de dar cuenta de que lo que propuse asume que se ha aplicado el parche en drupal.org/node/1064472 , que olvidé mencionar. Respuesta editada.)
smokris

1
Gracias smokris. El enlace fue muy útil. Tuve una suposición errónea sobre cómo se manejó el campo / instancia. Su respuesta ahora tiene sentido para mí, y el enlace al parche me salvará de arrancarme el cabello :)
Ashlar

1
El parche mencionado para las características D7 ahora se ha comprometido a dev drupal.org/node/1064472#comment-7235792
danbohea

1

Esta solución funcionó muy bien para mí, mucho más robusta para exportar a varios sitios que crear una tercera característica, que crearía campos huérfanos en otro sitio no relacionado.

http://drupal.org/node/1698290


0

Una solución que funcionó para mí fue unir las dos características en una característica más grande, lo que resolvió los conflictos.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.