cuándo usar archivos de inclusión (inc) en el desarrollo de módulos

Creo que entiendo las diferencias estructurales de un archivo .inc (en comparación con un .module), pero ¿alguien podría describir las diferencias de diseño? Veo módulos de ejemplo de drupal que llaman a un archivo .inc con hook_menu, o veo al archivo .inc de llamada para las definiciones de funciones.

¿En qué circunstancias se pone código en un archivo .inc? ¿Alguna pauta general de diseño a la que se adhieran algunos?
¿Hay alguna otra ventaja además de la claridad de por qué uno usaría un archivo .inc (o múltiple)? ¿actuación? versionado?

¡Gracias!

— Joe
fuente

No puede obtener una mejor explicación que la respuesta aceptada a esta pregunta en mi opinión :)

— Clive

personalmente, si tengo un mod que admite múltiples URL o lo que sea, utilizo una .incpor url. solo organización, supongo que en lugar de volcar funciones aleatorias en un .modulearchivo grande . pero como referencias de publicaciones de @ Clive, es realmente una opinión personal o lo que estás acostumbrado. No está bien o mal aquí.

— au_stan

de hecho, he usado modulename.preprocess.inc, modulename.node.inc, modulename.menu.inc, etc. para dividir módulos grandes en fragmentos razonables de funciones relacionadas, pero la única razón real desde cualquier punto de vista de rendimiento para usarlos fuera del desarrollo la organización es probablemente si su módulo tiene algunas funciones bastante grandes que rara vez se llaman que no desea que su motor php se analice cada vez que se carga. luego puede traerlos cuando sea necesario, al igual que cómo se hacen las cosas con la devolución de llamada del menú.

— Jimajamma

Para lo que vale, agrupo mis implementaciones de gancho y funciones auxiliares y clasifico sus bloques de documentos usando una convención de nomenclatura apropiada (en CAPITALS). Entonces, a medida que me desplazo por el código de mi módulo, puedo ver la separación entre los diferentes grupos de funcionalidad. Miré en los estándares de comentarios para ver si ya existía un sistema, pero pude ver uno.

— dbj44

Como regla general, pondría en el archivo del módulo el código que se requiere con más frecuencia (por ejemplo, funciones auxiliares utilizadas desde más de una función), y en los archivos .inc el código que no se utiliza con tanta frecuencia o que se utiliza para páginas

Desde Drupal 6, el código carga automáticamente los archivos que contienen las devoluciones de llamada de página o los creadores de formularios utilizados para los elementos del menú. Por esa razón, las devoluciones de llamada de página para páginas administrativas normalmente se colocan en archivos .admin.inc, mientras que la devolución de llamada de página para páginas normales se coloca en archivos .pages.inc.

Desde Drupal 7, los archivos que contienen clases se cargan automáticamente cuando se instancia una clase. Drupal 7 permite a los módulos definir en qué archivos se definen sus ganchos (a través de hook_hook_info () ). Por ejemplo, system_hook_info () define los archivos .tokens.inc como archivos donde hook_token_info(), hook_token_info_alter(), hook_tokens(), y hook_tokens_alter()las implementaciones se puede encontrar; de esta manera, esos archivos se cargan automáticamente cuando se requiere uno de esos enlaces.
Esto permite dividir aún más el código en archivos que se cargan cuando es necesario, y un código que siempre se carga desde Drupal.

— kiamlaluno
fuente