quand utiliser les fichiers include (inc) dans le développement du module

Je pense que je comprends les différences structurelles d'un fichier .inc (par rapport à un .module), mais quelqu'un pourrait-il décrire les différences de conception? Je vois des exemples de modules drupal appelant un fichier .inc avec hook_menu, ou je vois appeler un fichier .inc pour les définitions de fonction.

Dans quelles circonstances place-t-on du code dans un fichier .inc? Y a-t-il des directives générales de conception auxquelles certains adhèrent?
Y a-t-il un avantage autre que la clarté quant à la raison pour laquelle on utiliserait un (ou plusieurs) fichier .inc? performance? versionner?

Merci!

— Joe
source

Vous ne pouvez pas obtenir une meilleure explication que la réponse acceptée à cette question à mon avis :)

— Clive

personnellement, si j'ai un mod qui prend en charge plusieurs URL ou autre, j'utilise un .incpar URL. juste une organisation, je suppose, au lieu de vider des fonctions aléatoires dans un seul gros .modulefichier. mais comme références de publication de @ Clive, c'est vraiment juste une opinion personnelle ou ce à quoi vous êtes habitué. pas de bien ou de mal ici.

— au_stan

en effet, j'ai utilisé modulename.preprocess.inc, modulename.node.inc, modulename.menu.inc etc. pour décomposer de gros modules en morceaux raisonnables de fonctions connexes, mais la seule vraie raison de tout point de vue des performances de les utiliser en dehors du développement l'organisation est probablement si votre module a des fonctions assez grandes qui sont rarement appelées que vous ne voulez pas que votre moteur php analyse chaque fois qu'il est chargé. vous pouvez ensuite les apporter en cas de besoin, tout comme la façon dont les choses sont faites avec les rappels de menu.

— Jimajamma

Pour ce que ça vaut, je regroupe mes implémentations de crochet et les fonctions d'assistance et catégorise leurs blocs doc en utilisant une convention de dénomination appropriée (en MAJUSCULES). Donc, en parcourant le code de mon module, je peux voir la séparation entre les différents groupes de fonctionnalités. J'ai regardé dans les normes de commentaires pour voir si un système existait déjà, mais je pouvais en voir un.

— dbj44

En règle générale, je mettrais dans le fichier de module le code qui est requis plus souvent (par exemple, les fonctions d'assistance utilisées à partir de plusieurs fonctions), et dans les fichiers .inc le code qui n'est pas utilisé si souvent, ou qui est utilisé pour des pages.

Depuis Drupal 6, le code charge automatiquement les fichiers contenant les rappels de page, ou les générateurs de formulaires utilisés pour les éléments de menu. Pour cette raison, les rappels de pages pour les pages administratives sont normalement placés dans des fichiers .admin.inc, tandis que les rappels de pages pour les pages normales sont placés dans des fichiers .pages.inc.

Depuis Drupal 7, les fichiers contenant des classes sont automatiquement chargés lorsqu'une classe est instanciée. Drupal 7 permet aux modules de définir dans quels fichiers leurs hooks sont définis (via hook_hook_info () ). Par exemple, system_hook_info () définit les fichiers .tokens.inc sous forme de fichiers où hook_token_info(), hook_token_info_alter(), hook_tokens()et hook_tokens_alter()mises en œuvre peuvent être trouvées; de cette manière, ces fichiers sont automatiquement chargés lorsque l'un de ces hooks est requis.
Cela permet de diviser davantage le code en fichiers qui sont chargés si nécessaire et en code qui est toujours chargé depuis Drupal.

— kiamlaluno
source