[development] inferring which file to include based on page callback array

Larry Garfield larry at garfieldtech.com
Tue Jun 12 04:25:16 UTC 2007


If a module needs to use a function in another module that is a page callback, 
then the mechanism is already there to include it cleanly.

If a module needs to use a function in another module that is not a page 
callback, it should still be in the main .module file and therefore always 
available.

If a module author puts a function that is not a page callback into an include 
file, thus hiding it from other modules, that's a bug with that module and 
should be filed as such. :-)  

Page callbacks are low-hanging fruit.  They're easy to split off with little 
code and get a lot of performance benefits from.  Splitting off API functions 
and hooks is more difficult because they DO get called at random times, 
unlike page callbacks.  That's not to say it's impossible, but it's more 
difficult as you have to make sure it's always-callable and you don't balloon 
the number of includes on a page.  (Disk IO == expensive.)  The trade-off 
point there is far less clear.  

I actually originally wanted to allow multiple includes per menu entry in 
order to support library files (from another module or from /includes), but 
chx insisted we hold off on that for simplicity.  That's something we can 
revisit in D7 after we see how the page splitting works out.  

On Monday 11 June 2007, Moshe Weitzman wrote:
> ah, thats the other thing that annoyed me. this derogatory term "magic".
>   larry commented in the issue that module developers need full control
> over function naming and so on. this is laughable. drupal already has
> strict conventions for function naming - the hook system. my proposal is
> more of the same, except is is a convenience not a requirement. these
> are *conventions*, not magic. conventions are powerful, and are popular
> in many apps like drupal and rails.
>
> "we have so much legacy code". all that code is not affected until you
> start splitting up your module into .inc files. this is a moot point.
>
> we can keep the include element if people want to, so they can include
> random files. that will solve the desire to put an export_ function in
> the admin file.
>
> this isn't just about the menu system. i think we've hurt
> interoperability of modules with larry's patch. i think modules are
> going to have to start including each others files in order to get the
> features they want. thats dirty. it shouldn't happen, but it will. my
> proposal gets us past that. all a module developer has to do is use
> module_invoke(<other module>, <function>) and the right includes will
> happen. this isn't foolproof, but i do think it is an improvement.
>
> Peter Wolanin wrote:
> > This seems like a little too much "magic" in terms of the file and
> > function naming, and perhaps too rigid as well.  What if I want to
> > include both admin and export function in one .inc file?
> >
> > -Peter
> >
> > On 6/11/07, Moshe Weitzman <weitzman at tejasa.com> wrote:
> >> you do so based on the first part of the function. so in my example
> >> below, 'admin' is the part and thus system.admin.inc is known. sorry, i
> >> omitted that. it was buried in the issue where larry added the include
> >> parameter. that file would only be included if it existed, of course.
> >>
> >> Peter Wolanin wrote:
> >> > Moshe - how does this make sense?  You no longer know which file to
> >> > include for the callback.
> >> >
> >> > -Peter
> >> >
> >> > On 6/11/07, Moshe Weitzman <weitzman at tejasa.com> wrote:
> >> >> CURRENT
> >> >>    $items['admin/build'] = array(
> >> >>      'title' => 'Site building',
> >> >>      'page callback' => 'system_admin_menu_block_page',
> >> >>      'file' => 'system.admin.inc',
> >> >>
> >> >> PROPOSED
> >> >>    $items['admin/build'] = array(
> >> >>      'title' => 'Site building',
> >> >>      'page callback' => array('system, 'admin_menu_block_page'),
> >> >>    (
> >> >>
> >> >> Note that we may still have to support a string as a page callback (i
> >> >> think) for non module defined callbacks.


-- 
Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson


More information about the development mailing list