Posted by oskar_calvo on September 6, 2011 at 8:37am
Buenos días gente.
Hay muchos tipos de proyectos en Drupal, y yo suelo tener la suerte (no se si buena o mala) de encontrarme con proyectos que requieren de muchos módulos a medida.
En el trabajo estamos debatiendo de como deberían programarse los módulos, esto es que funcionalidades debería tener cada módulo.
Tenemos en mente dos opciones por similitud de hooks, o por entidades.
Por similitud de hooks
:sería, tener un módulo para todos los form_alter, otro para todos los nodeapi, otro para todos los preprocess_node, etc....
Por objeto
:La segunda opción es para el tipo de nodo crear un módulo en el que este su preprocess, su nodeapi, su form_alter, etc...
Esto es para tener todos los "custum modules" más organizados.
¿Opiniones?
Oskar
Comments
Opción b)
Aunque por lo que comentas, parece poco reaprovechable por ser desarrollos para proyectos muy específicos, la opción de hacerlo por dominios relacionados (tipos de contenido, nodos) te permite reaprovechar los módulos en otros proyectos si fuera necesario, que es el objetivo de la modularidad.
En el primer caso, no habría forma sin incluir todos los módulos, y para eso meterías todo en uno sólo, ¿no?
--
Christian López Espínola (@penyaskito)
Si es uno de los puntos que
Si es uno de los puntos que estamos debatiendo.
Al ser cosas muy concretas no se pueden "compartir".
Por otro lado, nos estamos apoyando en features para todo lo que vaya por features ir agregandolo al .module de la feature, o a *.include de la misma, ya que al actualizar las features ni toca los .module ni ningún otro archivo que se añada.
Pero otras veces, sobre todo por "temas" sacamos nodos generales de prepocess_page y preprocess_node, por si hay que actualizar el tema no tocar estas funciones.
Oskar
Parece que por cuestiones
Parece que por cuestiones relacionadas con la modularidad y la independecia semántica es más conveniente tenerlo todo organizado por entidades pero creo que hay veces en las que tener un solo form_alter y un nodeapi (o por lo menos en estos casos) puede llegar a ser más conveniente tenerlo agrupado por el hecho de aumentar la eficiencia de Drupal a la hora de hacer los "invoke" de cada uno de ellos en los diferentes módulos custom ya que una vez dentro de esas funciones todo es controlado mediante un único switch (que desde luego siempre será más rápido que tener diferentes funciones).
/**
* Pablo Martín Muñoz
* Open SOurce Architect & Data Scientist
* http://edipotrebol.es
**/
Por feature
La primera no me convence porque se rompe el objetivo de la modularidad, que es precisamente mejorar el desacoplamiento para poder activar o desactivar partes del sistema sin tocar las demás.
La segunda tampoco, ya que considero que el tipo de nodo no debería ser el núcleo de un módulo. Hay módulos, de hecho, que no tienen por qué definir tipos de nodo. Otros que, aunque actúen sobre el mismo tipo de nodo, tienen objetivos muy diferentes.
Mi punto de vista es que los módulos deben ofrecer funcionalidades bien definidas y autónomas, por lo que lo que ofrece el módulo es el centro de la cuestión.
Para proyectos grandes y funcionalidades muy complejas, si se quiere un sistema más o menos dinámico, crearía un módulo base que sirviera de punto de anclaje a submódulos con funcionalidades más específicas o de más alto nivel.
En definitiva, reducir el acoplamiento me parece demasiado importante.
¡Un saludo!
Gracias a todos por las
Gracias a todos por las respuestas.
Como se puede ver, dependiendo de lo que se busque es mejor una cosa u otra.
Como se ha dicho, mejor un único hook_form_alter, o un hook_nodeapi, los preprocess_page y _node en para tener todos los códigos, ya que se evita tener que crear cargar n módulos para los diferentes objetos.
Pero si se quiere nosotros estamos utilizando como base las features para agregar en las mismas los códigos de nodeapi y preprocess para poder reusarlas en diferentes proyectos, pensemos en features del tipo
*blog
*noticias
*landingpages
etc..
Y lo mismo para las vistas
Pero cuando se empiezan a crear módulos a niveles más básicos como módulos de estadísticas, gestión de invitaciones, etc... en ese caso nosotros estamos creando módulos que agrupan todo lo que estos módulos utilizan.
Así y todo, no termino de estar 100% satisfecho, porque no veo que responda tanto a un orden lógico, sino a una aproximación necesaria de solventar una necesidad.
Un saludo
Oskar
Creo que esa característica
Creo que esa característica difusa de los problemas es lo que le da sentido al ser humano. Si no, todo lo harías las maquinas (lo siento, soy muy fan de Matrix lol). Es imposible estar al 100% de acuerdo con algo pero yo comparto tu comentario al 100% ;) Yo para algunas cosas agrupo en nodeapi y form_alter por eficiencia pero si quiero realizar una funcionalidad independiente y que pueda ser exportada como módulo pues lo encapsulo de forma diferente.
/**
* Pablo Martín Muñoz
* Open SOurce Architect & Data Scientist
* http://edipotrebol.es
**/
Clean Code propone los
Clean Code propone los siguientes mandamientos:
Uno de los, a mi modo de ver, puntos débiles del API de Drupal 6 es su abuso de operandos en los hooks (como nodeapi() o user()), que afortunadamente corrigieron en Drupal 7. Estos $op provocan que las funciones sean largas y complejas, rompiendo con el primero de los puntos comentados arriba. Si además empezamos a apelotonar todos los hooks en uno solo, y si hablamos de proyectos grandes (¿10 o 15 hook_nodeapi() custom?), independientemente de si la web está hecha en Drupal 6 o 7 cualquier pequeño cambio puede suponer un lío tremendo.
Seguir esa estrategia puede resultar, en mi opinión, muy caro desde el punto de vista de la mantenibilidad. Cuanto mayor sea el proyecto, más spaghettizado estará el código y mayor será el coste. Tengamos en cuenta que el código se escribe una vez, pero se mantiene durante el resto de su vida.
Si bien es cierto que a mayor número de módulos, peor rendimiento, es necesario hacer benchmarkings para averiguar cuál es el impacto real de este factor en el site. Antes de tomar decisiones que pueden resultar muy caras en el futuro, es preferible averiguar si podemos optimizar el rendimiento del sistema sin renunciar a la calidad del código.
@edipotrebol -
@edipotrebol - @carlescliment
En estas estoy, como se que un pequeño fallo te acompaña de por vida, ahora que estamos con el desarrollo queremos tenerlo todo bien definio. Y aunque la documentación la llevamos al día, incluso con un sistema de un módulo para la gran mayoría de form_alter y luego otros form_alter en otros módulos no es lo más cómodo de actualizar.
Es cierto que mi compañera y yo nos conocemos los módulos muy bien. No así los nuevos reclutas, y ese es el problema. Estamos buscando una forma lo más óptima posible.
Es cierto que se tira mucho de nodeapi/ user, pero solo cuando se implementan mal, he visto cosas mucho peores como muchas implementaciones de nodeapis meterlas en los preprocess de nodo o de página porque es más sencillo.
Por otro lado, crear un módulo por cada hook_form_alter, nodeapi, etc... me parece demasiados módulos muy pequeños que en todos los casos tienen que tener si o si un *.info y un *.module .
Por ahora vamos por el camino de en medio, para algunas cosas que queremos re-utilizar en otros proyectos features con esteroides, cuando hay que agrupar hooks, sobretodo form_alter, nodeapi, user en un único módulo.
Para cosas muy concretas que llevaría algo más que esa función, y que esta relacionado con todo el módulo en sí, por ejemplo el de métricas de la web lo hemos agrupado dentro dentro del módulo.
Así y todo, no estoy contento al 100% con el resultado.
Un saludo
Oskar
pd: Gracias por la terapia de grupo :p