[development] The Drupal Diet - Making bootstrap faster

[Larry Garfield]

On Thu, 3 May 2007 07:43:19 -0400, "Doug Green" <douggreen at douggreenconsulting.com> wrote:
> +1 for the idea
> 
>> Sooo...  Now that the three of you who made it all the way through this
>> email have gotten here, thoughts on this approach?  Any caveats I'm
>> missing?  Any use cases I don't know about?  Does this have a snowball's
>> chance in hell of being accepted?
> 
> Maybe I missed something....
> 
> Why not simply start by adding a .page for pages and .form for forms?  If
> the function doesn't exist when it's needed, look for it in the module
> directory.  Or is this what you've already done?

There's two reasons why we can't do that.

1) user_menu() defines menu callbacks that specify a function in system.module.  I've written contribs that specify node_add(), views_get_view(), and panels_get_panel() (or whatever that function is called...) as a page callback.  We have to allow cross-module callbacks.  We can determine the module that declares the menu item at menu_rebuild() time, but we can't determine the module that provides a function at page load time unless it's been pre-determined because our module naming scheme is ambiguous.  The same holds true for forms; the form id and callback function do not adequately identify the providing module.  (If someone has an idea for how we can efficiently and definitively determine the providing module for a page or form handler by its name alone, please tell me!)

2) By mandating .pages and .forms, we disallow module authors from further factoring their code out.  system.module, for instance, breaks down fairly neatly into 3 different "sets" of page handler functions.  We want to allow that module to get split 3 ways instead of just one.  Views is another textbook example.  One of the added benefits of this task is that the Views UI and Views Theme Wizard modules can simply get folded into the main Views module in their own (separate) page library files.  That way they're always available but don't take up load time.

> Similar factoring could occur for hooks as well.  Is this the
> over-factoring
> you want to avoid?

Factoring out hooks is something I'm not dealing with at the moment, as that offers other challenges I don't want to deal with right now.  I was talking more about utility functions that module authors may put into their page files instead of their .module files, for which I propose a solution of "file a bug with the module author for doing it wrong". :-)

> I don't like having to pass an additional argument telling the system
> where
> things live.  I think it should have pretty good defaults that work most
> of
> the time, and the path argument only overrides in special cases.

The default that works all of the time is the "leave things in the .module".  The additional code to put page callbacks elsewhere is one line per menu item.  For forms, it's one line per form item in hook_forms(), although it does add the requirement that one use hook_forms().  I can't think of a simpler way that will work in all cases.


--Larry Garfield