I am just starting to look at Zend Framework 2 (and am new to ZF in general), and in the user guide, they are using autoloading when adding a new module. However, I find the explanation to be quite challenging for a rookie. They are adding a Module.php file within the module directory, which among others contains the following code:
public function getAutoloaderConfig()
{
return array(
'Zend\Loader\ClassMapAutoloader' => array(
__DIR__ . '/autoload_classmap.php',
),
'Zend\Loader\StandardAutoloader' => array(
'namespaces' => array(
__NAMESPACE__ => __DIR__ . '/src/' . __NAMESPACE__,
),
),
);
}
Now I did some digging around to try and figure out what this autoloading is all about. As far as I understand, the autoloading uses spl_autoload_register() and is a way to avoid having require_once() everywhere in the code. So, when trying to use a class that is not defined, the autoload() method that was registered will be run, which simply does an array lookup and includes the file like below if it was added.
// Zend/Loader/ClassMapAutoloader.php
public function autoload($class)
{
if (isset($this->map[$class])) {
require_once $this->map[$class];
}
}
This seems clever due to performance. I hope what I just wrote is correct. Based on this, I am trying to figure out what is going on in getAutoloaderConfig() from the first code snippet, but I am quite confused. It seems as if the array that is returned by this method is used for AutoloaderFactory::factory(), but I am not sure for what purpose. Instantiating autoloaders with options it seems, but exactly what that does, I am not sure. I guess the second entry of the array specifies where to find the source files for the module's namespace - at least that would be my guess. The first entry I am, however, not sure about. In the user guide, it says the following:
As we are in development, we don’t need to load files via the classmap,
so we provide an empty array for the classmap autoloader.
The file just returns an empty array. I am not sure what the purpose of this ClassMapAutoloader.
Sorry if my point is unclear; basically I am trying to figure out what is happening in getAutoloaderConfig() and what mymodule/autoload_classmap.php is used for. If someone could shed some light on this, that would be much appreciated!
The classmap is there to show PHP the most direct way to a class. It's essentially saying "You you're looking for A\Class\Youre\Looking\For, look no further than this file: xyz.php. This would be expressed like this:
return array(
'A\Class\Youre\Looking\For' => ___DIR__.'/xyz.php'
)
Without it PHP has to run through the whole autoloader chain, which can be pretty expensive. Why is it saying something about "as we're in development"? Because classmap files are typically generated on the production server by some script. Basically, just don't worry about it too much right now. It's micro-optimization...
The getAutoloaderConfig() method is just there to give you some flexibility in really advanced applications. Most of the time you can just use the SkeletonApplication's and SkeletonModule's boilerplate code and leave it alone. Really, you can even kill the 'Zend\Loader\ClassMapAutoloader' => array(__DIR__ . '/autoload_classmap.php',) part for now.
It's just a hook for future improvements and nothing to worry about too much if you're just starting out with ZF2 (like me ;).
ZF2 has a number of autoloaders available.
The 2 most common (or the 2 which developers interact with directly at any rate) are Zend\Loader\ClassMapAutoloader and Zend\Loader\StandardAutoloader.
The classmap autoloader is usually used at the module level to
provide a simple but fast array lookup mechanism. It is configured
with an associative array of key => value pairs, with the key
representing the class, and the value representing the filename
which defines the class.
The standard autoloader, on the other hand, is designed to hold a
list of "namespaces" and base directories. What is does is to then
build the path to the class referenced, but not yet loaded, by
prepending the base directory path for that namespace to the class
name, to arrive at the final absolute path to the class file, which
it then tries to include. You can quickly populate the
classmap_autoload.php file by running either
/path/to/ZF2/bin/classmap_generator.php or zftool.phar generate
classmap.
Zend\Loader\AutoloaderFactory is designed to manage the various autoloaders, and to make sure there are no conflicts. Ultimately, of course, all autoloading capabilities leverage PHP SPL autoloading.
The purpose of getAutoloaderConfig() is to identify to the autoloader factory which autoloaders are available for this module's namespace.
In the example shown above, that would be, in order of preference, the classmap autoloader, followed by the standard autoloader. If you don't wish to use the classmap autoloader for that module, simple remove the reference from the array returned by getAutoloaderConfig().
The method name getAutoloaderConfig() is reserved. If this method is defined, during the module initialization process, a listener (Zend\ModuleManager\AutoloaderListener) is attached which retrieves the configuration returned by this method, and adds it to the consolidated configuration.
A web application consists of many PHP classes, and
each class typically resides in a separate file. This introduces
the need of including the files.
As your application grows in size, it may be difficult to include
each needed file. Zend Framework 2 itself consists of hundreds of files,
and it can be very difficult to load the entire library and all its
dependencies this way. Moreover, when executing the resulting code, PHP interpreter will
take CPU time to process each included file, even if you don't create an
instance of its class.
To fix this problem, in PHP 5.1, the class autoloading feature has been introduced.
The PHP function spl_autoload_register() allows you to register
an autoloader function. For complex web sites, you even can create
several autoloader functions, which are chained in a stack.
During script execution, if PHP interpreter encounters a class name
which has not been defined yet, it calls all the registered autoloader functions
in turn, until either the autoloader function includes the class or "not found" error is
raised. This allows for "lazy" loading, when PHP interpreter processes the class
definition only at the moment of class invocation, when it is really needed.
Because each library's vendor uses its own code naming and file organization conventions,
you will have to register a different custom autoloader function per each dependent library,
which is rather annoying (and actually this is an unneeded work). To resolve this problem,
the PSR-0 standard was introduced.
The PSR-0 standard
(PSR stands for PHP Standards Recommendation)
defines the recommended code structure that an application or library must follow
to guarantee autoloader interoperability.
Each module of the web application registers an autoloader, which makes it possible to autoload
any PHP class in your modules. This is made with the getAutoloaderConfig() method of the Module class.
ZF2 has a special component named Zend\Loader, which contains implementations
of the two commonly-used autoloader classes: the standard autoloader (Zend\Loader\StandardAutoloader)
and class map autoloader (Zend\Loader\ClassMapAutoloader).
The fact that ZF2-based application modules conform to PSR-0 standard makes it possible to use the standard autoloader.
The class map autoloader can be used as a faster replacement for the standard autoloader.
This autoloader expects you to pass it a class map array. Each key=>value pair of the class
map is, respectively, the class name and path to the PHP file containing the class.
The concept of autoloading in Zend Framework 2 is well explained in Using Zend Framework 2 book.
Related
This is my project path configuration
./create.php
/Install/Install.php
create.php
<?php
use Install\Install;
echo "Starting";
$install = new Install();
This gives me the error
PHP Fatal error: Uncaught Error: Class 'Install\Install' not found in /project/create.php:6
Install.php
<?php
namespace Install;
class Install
{
//whatever
}
Can someone explain me what is happening there ?
Obviously I guess that using a require_once line with my filename would probably fix the issue...but I thought using namespace and use import could prevent me from doing that like we do in classic framework like symfony / magento ?
I've seen some post speaking about autoloading, but i'm a little bit lost. Haven't been able to find a clear explanation on the other stack topic neither.
PHP compiles code one file at a time. It doesn't have any native concept of a "project" or a "full program".
There are three concepts involved here, which complement rather than replacing each other:
Namespaces are just a way of naming things. They allow you to have two classes called Install and still tell the difference between them. The use statement just tells the compiler (within one file) which of those classes you want when you write Install. The PHP manual has a chapter on namespaces which goes into more detail on all of this.
Require and include are the only mechanisms that allow code in one file to reference code in another. At some point, you need to tell the compiler to load "Install.php".
Autoloading is a way for PHP to ask your code which file it should load, when you mention a class it hasn't seen the definition for yet. The first time a class name is encountered, any function registered with spl_autoload_register will be called with that class name, and then has a chance to run include/require to load the definition. There is a fairly brief overview of autoloading in the PHP manual.
So, in your example:
use Install\Install; just means "when I write Install, I really mean Install\Install"
new Install() is translated by the compiler to new Install\Install()
the class Install\Install hasn't been defined; if an autoload function has been registered, it will be called, with the string "Install\Install" as input
that autoload function can then look at that class name, and run require_once __DIR__ . '/some/path/Install.php';
You can write the autoload function yourself, or you can use an "off-the-shelf" implementation where you just have to configure the directory where your classes are, and then follow a convention for how to name them.
If you want to Use class from another file, you must include or require the file.
Use require('Install.php'); before use Install\Install;.
If you are planning to do a big project I would recommend to use PHP frameworks rather than coding from scratch.
I've seen a lot of threads here and in other forums that asked this a lot of times, but I still see using the include function of PHP in the answers?
how can I use this function, not using totally the include function?
Thank you
how can I use this function, not using totally the include function
You cannot totally not use include and that is not the point of using autoloader as you usually need to at least include the autoloader ;). That autoloader is the regular PHP code that is being called by PHP when unknown class use is attempted in the code. It is expected to include right file to make the class known, and the code continues as you'd explicitely include right file by hand in your code. So the main benefit shows up when your code uses classed (OOP) - you do not need to care if you included the class you are about to instantiate the object of or not. You just do new Foo() or call Something::methodName() and if all is set up right it will work.
The function spl_autoload_register is used to register a callback into the autoloader queue.
The PHP autoloader is a functionality of the PHP interpreter that, when a class is not defined, calls the functions registered in the queue, one by one, asking them to load the class, until the class becomes available. It the class is still not available after all the functions were invoked, the interpreter triggers a fatal error.
The autoloader doesn't perform any magic. It is the entire responsibility of the registered functions to make the class available. Most of them use the name and namespace of the missing class to figure out the path of the file that contains the declaration of the class and include it.
That's how the thing works. There are not many ways to produce a class in PHP and, for a reusable autoloader callback, the list starts and ends with include1 (include_once, require or require_once can be used as well but they don't make any difference in this case.)
The autoloader callback itself stays in separate file (for reusability) and usually that file also contains its registration as autoloader callback (the call to spl_autoload_register). All your code have to do is to include this file once in every file that is an entry point of your application.
All things being equal, your application needs to use include at least once and once is also the maximum required number of usages for it. The autoloader callback also uses include (probably also only once) but you don't write autoloader callbacks every day. If you wrote one and you wrote it well you can reuse it. Most people never wrote an autoloader callback and they will never write one.
Using Composer is easy and if you follow the PSR-4 rules of naming the files of your project, Composer can generate an autoloader for your project that knows how to load your classes (behind the scene it uses include, of course). All you have to do is to run composer init in the root directory of your project, run composer install and write include 'vendor/autoload.php'; in the file that represents the entry-point of your application. No other uses of include are required.
1 An autoloader callback is not required to include another file to make the class available. It can generate the code of the class on the fly and eval()-uate it, but the use cases of such approach are very limited. It is used by the testing suites f.e., to generate mock classes.
I've dicided to rewrite autoloader that currently exists in project, to replace an old __autoload() with spl_autoload_register(). While searching for an optimal solution, I've found this most upvoted commentary on php.net, that states:
Good news for PHP 5.3 users with namespaced classes:
When you create a subfolder structure matching the namespaces of the
containing classes, you will never even have to define an autoloader.
So basic realization is simple:
class Autoloader
{
function __construct() {
spl_autoload_extensions('.php');
spl_autoload_register();
}
}
And adding subfolders with same namespaces allows to minimize amount of boot operations to this:
require('bone/classes/autoloader.php');
$autoloader = new bone\classes\Autoloader;
#Start working with classes...
$custom_class = new meat\classes\Custom_class;
While this looks small and fast, the question is:
Is there any huge problems this solution could lead to in future? Because, for example, Zend/Symphony loaders are much more complex, and I believe for a good reason.
(For example, adding a "vendor" prefix to namespaces - according to PSR-0 - could be a bit of a problem, because it should match directory as well - a webroot directory)
Hoping to receive any constructive point of view. Thank you.
Problem
I am using the SPL Class Loader provided by PSR Group. However, I've come to a chicken-egg paradox.
That is, this will autoload classes preventing explicitly including them. But I first need to include/require this class and the code for instantiating the object
$classLoader = new SplClassLoader('Doctrine\Common', '/path/to/doctrine');
$classLoader->register();
Question
What is common solution for including the autoloader code?
In the case of a front-end controller, I could add the code there. But I'm not always using the front-end controller patter. I suppose I could also use PHP's auto_prepend_file. Interested in the communities input.
You explicitly require the autoloader on the bootstrap stage (the stage where the application is started up).
All subsequent functions/classes are then autoloaded.
I have asked a similar question to this one already but I think it was badly worded and confusing so hopefully I can make it a bit clearer.
I am programming in a native Linux file system.
I have a class of HelpTopic:
class HelpTopic extends Help{}
And a class of Help:
class Help{}
Now I go to include HelpTopic:
include('HelpTopic.php');
And even though I do not instantiate HelpTopic with new HelpTopic() PHP (in a Linux file system) still reads the class signature and tries to load Help with HelpTopic.
I do not get this behaviour from a cifs file system shared from a Windows System.
My best guess is that there is some oddity with Linux that causes PHP to react this way but not sure what.
Does anyone have any ideas or solutions to this problem?
EDIT:
I have added my loading function to show what I am doing:
public static function import($cName, $cPath = null){
if(substr($cName, -2) == "/*"){
$d_name = ROOT.'/'.substr($cName, 0, -2);
$d_files = getDirectoryFileList($d_name, array("\.php")); // Currently only accepts .php
foreach($d_files as $file){
glue::import(substr($file, 0, strrpos($file, '.')), substr($cName, 0, -2).'/'.$file);
}
}else{
if(!$cPath) $cPath = self::$_classMapper[$cName];
if(!isset(self::$_classLoaded[$cName])){
self::$_classLoaded[$cName] = true;
if($cPath[0] == "/" || preg_match("/^application/i", $cPath) > 0 || preg_match("/^glue/i", $cPath) > 0){
return include ROOT.'/'.$cPath;
}else{
return include $cPath;
}
}
return true;
}
}
I call this by doing glue::inmport('application/models/*'); and it goes through including all the models in my app. Thing is PHP on a linux based file system (not on cifs) is trying to load the parents of my classes without instantiation.
This is a pretty base function that exists in most frameworks (in fact most of this code is based off of yiis version) so I am confused why others have not run into this problem.
And even though I do not instantiate HelpTopic with new HelpTopic() PHP still reads the class signature and tries to load Help with HelpTopic.
Correct.
In order to know how to properly define a class, PHP needs to resolve any parent classes (all the way up) and any interfaces. This is done when the class is defined, not when the class is used.
You should probably review the PHP documentation on inheritance, which includes a note explaining this behavior:
Unless autoloading is used, then classes must be defined before they are used. If a class extends another, then the parent class must be declared before the child class structure. This rule applies to class that inherit other classes and interfaces.
There are two ways to resolve this problem.
First, add a require_once at the top of the file that defines the child class that includes the file defining the parent class. This is the most simple and straight-forward way, unless you have an autoloader.
The second way is to defione an autoloader. This is also covered in the documentation.
The ... thing ... you're using there is not an autoloader. In fact, it's a horrible abomination that you should purge from your codebase. It's a performance sap and you should not be using it. It also happens to be the thing at fault.
We don't have the definition of getDirectoryFileList() here, so I'll assume it uses either glob() or a DirectoryIterator. This is the source of your problem. You're getting the file list in an undefined order. Or, rather, in whatever order the underlying filesystem wants to give to you. On one machine, the filesystem is probably giving you Help.php before HelpTopic.php, while on the other machine, HelpTopic.php is seen first.
At first glance, you might think this is fixable with a simple sort, but it's not. What happens if you create a Zebra class, and then later need to create an AlbinoZebra that inherits from it? No amount of directory sorting is going to satisfy both the "load ASCIIbetical" and the "I need the Zebra to be first" requirements.
Let's also touch on the performance aspect of the problem. On every single request, you're opening a directory and reading the list of files. That's one hell of a lot of stat calls. This is slow. Very slow. Then, one by one, regardless of whether or not you'll need them, you're including the files. This means that PHP has to compile and interpret every single one of them. If you aren't using a bytecode cache, this is going to utterly destroy performance if the number of files there ever grows to a non-trivial number.
A properly constructed autoloader will entirely mitigate this problem. Autoloaders run on demand, meaning that they'll never attempt to include a file before it's actually needed. Good-performing autoloaders will know where the class file lives based on the name alone. In modern PHP, it's accepted practice to name your classes such that they'll be found easily by an autoloader, using either namespaces or underscores -- or both -- to map directory separators. (Meaning namespace \Models; class Help or class Models_Help would live in Models/Help.php)
Unfortunately most examples won't be useful here, as I don't know what kind of weird things your custom framework does. Take a peek at the Zend Framework autoloader, which uses prefix registration to point class prefixes (Model_) at directories.