PHP Include – Single Complex vs Multiple Simple Autoload Functions

includePHP

Using the spl_autoload_register(), should I use a single autoload function that contains all the logic to determine where the include files are or should I break each include grouping into it's own function with it's own logic to include the files for the called function? As the places where include files may reside expands so too will the logic of a single function. If I break it into multiple functions I can add functions as new groupings are added, but the functions will be copy/pastes of each other with minor alterations.

Currently I have a tool with a single registered autoload function that picks apart the class name and tries to predict where it is and then includes it. Due to naming conventions for the project this has been pretty simple.

if has namespace 
  if in template namespace look in Root\Templates
  else look in Root\Modules\Namespace
else
  look in Root\System
if file exists include

But we are starting to include Interfaces and Traits into our codebase and it hurts me to include the type of a thing in it's name. So we are looking at instead of a single autoload function that digs through the class name and looks for the file and has increasingly complex logic to it, we are looking at having multiple autoload functions registered. But each one follows the same pattern and any time I see that I get paranoid about code copying.

function systemAutoloadFunc
  logic to create probable filename
  if filename exists in system include it and return true
  else return false

function moduleAutoloadFunc
  logic to create probable filename
  if filename exists in modules include it and return true
  else return false

Every autoload function will follow that pattern and the last of each function if filename exists, include return true else return false is going to be identical code. This makes me paranoid about having to update it later across the board if the file_exists include pattern we are using ever changes. Or is it just that, paranoia and the multiple functions with some identical code is the best option?

Best Answer

Registering multiple autoloaders lets you separate different naming conventions for directory and file names and will be easier to maintain in the long run.

Imagine needing to add or remove functionality for the autoloader. Should you need to dive into a monolithic function or simply tweak or add a smaller function?

Similar calls to "file_exists() / include() / return" can be put into a helper function instead of copypasting that code.

function autoload_attempt($path){
    if (file_exists($path)) {
        include $path;
        return true;
    } else return false;
}

spl_autoload_register(function($class){
    $path = ... naming logic ...
    return autoload_attempt($path);
});

Registering different ones also gives you easier control over what order they are invoked. For example, if you want to have a master override directory, you would register that first.

From the manual: http://php.net/manual/en/function.spl-autoload-register.php

If there must be multiple autoload functions, spl_autoload_register() allows for this. It effectively creates a queue of autoload functions, and runs through each of them in the order they are defined. By contrast, __autoload() may only be defined once.

Related Solutions

PHP MVC – Error Handling, View Display, and User Permissions

There is no single proper approach to your problems even within MVC pattern so simple answer to your questions does not exist.

1 Error handling

If you are using the PDO you can change error handling by setting PDO::ATTR_ERRMODE so you don't have to use exceptions but regardless of the way errors are returned it is a programmers responsibility to handle them properly. If your method is returning false if the user doesn't exists then the controller should check what value was returned. There is no such thing as "controller assumes" it only means that the programmer assumed and didn't check returned value.

There are different errors which should be handled in different way some of them may require only showing error message some of them may be critical (like no db connection). You can use messages, views or additional controller to handle errors.

2 The proper way to show a view

Code from your example would be usually handled by the layout (header, footer, different element placement) and by the controller (using different views depending on the request). It is not good idea to use 'include' directly rather wrap it in the method. You can also create view class which would be responsible for handling views. view != .phtml

3 Managing user rights

In MVC pattern used for web applications there is usually additional "front controller" and permission checking will be handled there. You have to check for permission with each request and each request will require access to specific controller/method if you implement proper ACL it should resolve all your problems with user rights.

PHP Include Files – Many vs One Large File

tl;dr it's not many include files vs one large file, it's the Drupal way.

Since you want to move onto Drupal, I'd suggest you go with it for real. Here is how Drupal works.

First, in Drupal, the only folder you can touch is sites/.

In sites/default, basically you only touch the settings.php file. Most of your time will be spent in sites/all/. In this folder, there are 2: themes and modules. Your theme will be where you guess it, and the modules (contributed, or yours) will be where you guess it too.

I won't write a tutorial about how to write themes. Basically, you have all your templates in your theme, and the modules use these templates. The big advantage is that you can override the templates used by other modules (which you shouldn't touch either) including the core ones.

Drupal separates modules by features. You, for your own website, usually separate your modules by business features.

I'm not going to write a tutorial about how to write modules, but here is how it basically works:

Your module needs a .module file. Let's say your module is foo. So you have in folder in sites/all/modules/foo/. In there, you have a file named foo.info (with basic information), and another file named foo.module. In the foo.module file, you have this kind of stuff:

function foo_menu() {
    $items['bar'] = array(
        'title' => 'Some title',
        'page callback' => 'foo_answer_bar',
    );
    return $items;
}

function foo_answer_bar() {
    return 'Baz';
}

The principle is to have functions starting with your module name, and ending with specific names, such as _menu. These functions are picked up by Drupal and it handles them. In this example, the returned array tells Drupal to handle the /bar URL, and to display what the foo_answer_bar returns, in the layout.

Anyway. I'm not going further in this example, but what I'm saying is that if you go with Drupal, go with the Drupal way. It will be a little hard in the beginning, but a lot less painful in the long way. Try to keep many small modules rather one big module. The same rules as OOP apply there (SOLID, KISS, DRY).

Best Answer

Related Solutions

PHP MVC – Error Handling, View Display, and User Permissions

PHP Include Files – Many vs One Large File

Related Topic