Assuming the minimal module install (to keep things simple), what are the core "responsibilities" of the two top level functions in Drupal's index.php?
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
menu_execute_active_handler();
I'm trying to understand, from a high level, how Drupal's core systems work, particularly in relationship to web based MVC. So in a Code Igniter like system, the following
Examine the URL, turns it into a class and action
Calls the action method on the class, where information is loaded from models, "businessy logic" is done
Information is handed off to a view layer
Layout system renders HTML page
Part of the layout (often a "content area") is driven by the information handed off in step 3
What's the equivalent dispatch process in Drupal? I understand how the module system works, but I don't quite follow Drupal's philosophy on the how/why of data loading and theme/layout rendering, and where the handoff between the two happens.
I realize Drupal is radically different from web app MVC system; I'm trying to understand how. I realize Drupal is designe to be successfully used without fully understanding this. Preference given to Drupal 7 answers, but if there's been radical changes information from previous versions is welcome.
Good answers from Berdir and Apemantus already (+1), but some room for an additional try:
Concerning Drupals relationship to MVC, I took a stab at the topic with this answer to a question for 'A metaphor for Drupal module's inner workings', which might fit with your request for a 'high level' overview.
As for the top level function calls - well, some things just come in threes, so I would suggest taking the theme('page, $return) call into the mix, as this will complete the overview:
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
$return = menu_execute_active_handler();
// Menu status constants are integers; page content is a string.
if (is_int($return)) {
switch ($return) {
// [...] Snipped error page handling code
}
}
elseif (isset($return)) {
// Print any value (including an empty string) except NULL or undefined:
print theme('page', $return);
}
drupal_page_footer();
One by one:
drupal_bootstrap()
As the name suggests, this is mainly concerned with 'setting the stage', that is e.g.
An important point here is that already during this phase, the hook system will invoke other modules, if they ask for it, giving them a chance to inject custom logic in this early phase. While it is not common for modules to do this, it adds to the flexibility of Drupal that it can be done for special needs like e.g. influencing the user identification process, preventing or enforcing a cache hit, rewriting the requested path and other 'low level' manipulations.
menu_execute_active_handler()
This roughly matches steps 1. and 2. from your CodeIgniter sketch. It will inspect the requested path, match it to the proper callback function (including some 'turn wildcards into parameters' logic), and invoke that callback, passing the extracted (or predefined) parameters. The callback is usually expected to return the main page content, but is free to do other stuff like e.g. just redirecting the request. Most "businessy logic" will be done here, but note that the returned content is quite often already a Markup Fragment, so this phase includes some parts of the view layer already!
theme_page() (Indirectly invoked via the theme() function, which adds a lot of surrounding 'magic')
This (very) roughly matches the usual view layer, as this is where the final assembly of the markup to be returned takes place. But it is also the place where the 'surrounding' elements of a page get assembled (think menus, headers, sidebars, etc.) so there is still a lot of potential for "businessy logic" going on during this stage as well.
During all these steps, the hook system (along with the similarly designed theme system), will provide quite a number of 'hook in' points for other modules to 'subscribe' to, if they need to. When invoked, they will get passed the relevant information being processed at that point, with the option to step in and manipulate it (or just trigger some separate processing). All this adds up to a quite flexible system (because of the huge amount of 'intercept and manipulate' options for custom modules), but is also responsible for a lot of the difficulties in learning Drupal, as the question of 'what happens when' is often not easily answered :/
So to sum it up shortly: