quando usar arquivos de inclusão (inc) no desenvolvimento de módulos

Acho que entendo as diferenças estruturais de um arquivo .inc (comparado a um .module), mas alguém poderia descrever as diferenças de design? Eu vejo módulos de exemplo drupal chamando um arquivo .inc com hook_menu, ou vejo o arquivo .inc de chamada para obter definições de função.

Sob quais circunstâncias alguém coloca código em um arquivo .inc? Quaisquer diretrizes gerais de design às quais alguns aderem?
Existe alguma outra vantagem além da clareza de por que alguém usaria um (ou vários) arquivos .inc? desempenho? versionamento?

obrigado!

— Joe
fonte

Você não pode obter uma explicação melhor do que a resposta aceita para esta pergunta em minha opinião :)

— Clive

pessoalmente, se eu tenho um mod que suporta vários URLs ou o que seja, eu uso um .incpor URL. Apenas organização, eu acho, em vez de despejar funções aleatórias em um .modulearquivo grande . mas como as referências do post do @ Clive, é realmente apenas uma opinião pessoal ou com o que você está acostumado. não há certo ou errado aqui.

— au_stan 03/01

na verdade, usei modulename.preprocess.inc, modulename.node.inc, modulename.menu.inc etc para dividir grandes módulos em blocos razoáveis de funções relacionadas, mas a única razão real de qualquer ponto de vista de desempenho para usá-los fora do desenvolvimento organização é provavelmente se o seu módulo possui algumas funções bastante grandes que raramente são chamadas que você não deseja que o seu mecanismo php analise cada vez que é carregado. você pode trazê-los quando necessário, como a maneira como as coisas são feitas com o retorno de chamada do menu.

— Jimajamma

Para o que vale a pena, agrupo minhas implementações de gancho e funções auxiliares e categorizo seus blocos de documentos usando uma convenção de nomenclatura apropriada (em CAPITALS). Assim, ao rolar o código do meu módulo, posso ver a separação entre os diferentes grupos de funcionalidades. Eu olhei nos padrões de comentários para ver se um sistema já existia, mas eu podia ver um.

— dbj44

Como regra geral, eu colocaria no arquivo do módulo o código necessário com mais frequência (por exemplo, funções auxiliares usadas em mais de uma função) e, nos arquivos .inc, o código que não é usado com tanta frequência ou que é usado para fins específicos. Páginas.

Desde o Drupal 6, o código carrega automaticamente os arquivos que contêm os retornos de chamada da página ou os criadores de formulários usados para os itens de menu. Por esse motivo, retornos de chamada de página para páginas administrativas são normalmente colocados em arquivos .admin.inc, enquanto retorno de chamada de página para páginas normais são colocados em arquivos .pages.inc.

Desde o Drupal 7, os arquivos que contêm classes são carregados automaticamente quando uma classe é instanciada. O Drupal 7 permite que os módulos definam em quais arquivos seus ganchos são definidos (através de hook_hook_info () ). Por exemplo, system_hook_info () define os arquivos .tokens.inc como ficheiros onde hook_token_info(), hook_token_info_alter(), hook_tokens(), e hook_tokens_alter()as implementações podem ser encontrados; dessa maneira, esses arquivos são carregados automaticamente quando um desses ganchos é necessário.
Isso permite dividir ainda mais o código em arquivos carregados quando necessário e o código sempre carregado do Drupal.

— kiamlaluno
fonte