On Jan 23, 2007, at 4:34 PM, Gabor Hojtsy wrote:
Well, I am increasingly adopting a similar coding practice. A few days ago, I also split up archive.module into a small stub which registers the menu item and has a page callback, and then that page callback includes archive.inc which contains all the magic to display an archive page. This does eliminate a great deal of parsing for PHP. Although we use an opcode cache here, we observed greatly reduced memory usage if we take care of doing our own modules this way. (I don't have hard numbers unfortunately).
FWIW, I've been doing the same. To keep things consistent, each of my modules that's more than few hundred lines has a _module function that includes the inc file: function foo_menu($may_cache) { $items[] = array('path' => 'admin/user/foo', 'title' => t('Foo'), 'callback' => '_foo', 'callback arguments' => array('admin'), ); // ... return $items; } function foo_form($node) { return _foo('node_form', $node); } function _foo($func) { require_once dirname(__FILE__).'/foo.inc'; if (function_exists($func = '_foo_'.$func)) { $args = func_get_args(); unset($args[0]); return call_user_func_array($func, $args); } } And then, in the foo.inc file, I can implement _foo_admin, _foo_node_form and any other functions I'd want to call. Naturally, I try to keep all of the code required for normal operations in the .module file. (foo_user, view/load portions of foo_nodeapi, foo_block, etc) It would be counter-productive to invoke _foo() on every page load. Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies