What Do You Call Your Application "Initiator"?

EDIT: I would have to misspell initiator in the title now wouldn’t I

Most PHP applications have some kind of procedural file, which has the sole responsibility of including common resources like classes, functions, configuration, etc, and which may also define the __autoload() function and error/exception handlers.

I’m wondering what you all call this file. setup.php, initiator.php, boostrapper.php (bootstrap.php in CakePHP)? I seem to be calling this something different for every project, simply because all of the names I’ve used are ambiguous, and don’t make it clear enough what the file actually does. It could be assumed that “setup.php” is an installer-like utility, or that “initiator.php” is a kind of front controller.

Sorry it’s a terminology issue then. Where I’ve seen ‘bootstrap’ (a loose term anyway) used it was essentially acting as a front controller.

This seems backwards. Bootstrapping isn’t part of an application or a framework; it’s a technique for starting up a more complex application (or a framework). A Front Controller on the other hand, is part of that more complex application (or framework).

If using bootstrapping, the framework should know nothing about and have no knowledge of the bootstrap itself.

The purpose of the bootstrap, in terms of a framework, is to ensure everything is in place for the framework to properly run – think in terms of system requirements (required extensions, required PHP version, required configurations, etc) and files required to be loaded before the framework can start correctly. Once it has done this, it’s job is done and it releases control to the application or framework or “entry point”.

In other word, the bootstrap’s job is to load the application and get everything in place for it to run. The application itself deals with what to do with the request.

i.e, very simply:

<?php

try
{
    require 'Bootstrap.php';   
}
catch (Exception $e)
{
    /**
     * Failed to bootstrap the application!
     */
    die('Bootstrapping failed. See the system error log for more details.');
}

/**
 * Application is loaded; time to run
 */
Application_Controller::getInstance()->dispatch();

For old times’ sake, I tend to call the file index.php. It’s not a very strange file name to use as it’s known for all php-developers as the single point of entry to that specific folder. Also, it has a special meaning for Apache, in that it’s almost always listed in Apache’s DirectoryIndex directive.

The only procedural code within my own personal framework is inside the index page. There are only about 20 lines that set-up some path constants, instantiate application level dependencies. All other stuff is actually done inside a class that is responsible for initiating the program. I’ve never been a fan of the large procedural bootstrap myself. I’m able to avoid using a procedural configuration file through the use of a XML configuration file that is read in and assigned to the appropriate constants or properties. Based upon systems I have worked upon in the past I refer to what you call an “Initiator” as the master control program. The master control program is a facade that delegates all application level tasks, initializes the program and routes different types of requests to the appropriate action. By no means a standard just a pattern I’ve taken to based upon previous experiences with other software and seeing what works best for my needs and particular way of programming. If your familiar Joomla the MCP (master control program) is actually very similar in its purpose to the JFactory.

Ambiguous is right. Design patterns my friend, this is where Zend is probably best of all frameworks. They stick to the purest definition of the patterns I have seen yet.

Problem is, design patterns are specificall vague so many have been refined or further decomposed.

Many might say what you describe is a front controller, personally I would define it simply as index.php or your application entry point, which serves to fire up your application. I take it a step further and keep generic loading code in a bootstrap function, which then fires up the front controller, router, etc. This makes unit testing much easier I find. Plus you can easily reuse the same bootstrap for CLI, WEB, REST, etc.

Cheers,
Alex

I’d say that the ‘initiator’ has a different job to what’s often called ‘bootstrap’.

The initiator, or entry point deals with taking a HTTP request and passing it to the application.

The ‘bootstrap’, which I’ll refer to as the ‘front controller’, decides how the application deals with the request.

I believe the distinction is vital, it allows you to substitute the front controller, which for a reusable framework is very useful.

For example, I have 2 commonly use front controllers. The default one, and one which extends it to support multi-lingual sites (it looks for example, a valid locale as the first part of a request e.g. /en/foo/bar) , which one that’s used for a project can simply be chosen in the config file.

The file itself, I call index.php for the same reasons as webaddictz. If i’m bolting my framework onto an existing site (e.g. which is currently a bunch of HTML files, or poorly designed standalone .php files) I call it entry.php

edit: I don’t agree that this file should handle anything like autoload, error handling, etc. This should be set up in the front controller. It should only be an entry point to your application. This way, you can substitute $_GET for $_ARGV and everything works exactly as it did.