-- Artur Bodera <
[hidden email]> wrote
(on Friday, 28 October 2011, 03:54 PM +0200):
> Hi guys!
>
> After browsing those few beta modules that have been created for ZF2....
>
> Most modules have those files exactly the same
> - autoload_classmap.php
> - autoload_function.php
> - autoload_register.php
> (hence redundant)
<snip>
> Is there any special, hidden reasoning behind autoload_*.php files? :-)
<snip>
Please, please, please don't ignore the various posts (both on the ML
and in RFCs). We've indicated why we're recommending this structure, but
also that it's NOT REQUIRED.
As a refresher, the above three files allow a module to provide
autoloading information for a variety of use cases, some of which might
enable usage OUTSIDE Zend Framework. One goal of the module system is
re-usable, portable code... regardless of framework.
* autoload_classmap.php returns an associative array indicating a
classmap of PHP files available in the module. This can then be fed
into autoloaders that consume class maps.
* autoload_function.php returns a lambda that consumes the classmap
returned by autoload_classmap.php, suitable for feeding to
spl_autoload_register(). This is particularly useful if you want to
craft the priority at which the autoloader is registered, or if you
are using something like the autoloader in ZF1 (which implements its
own stack).
* autoload_register.php pass the lambda from autoload_function.php to
spl_autoload_register() with default priority. This is useful for
quickly consuming a module:
require_once 'path/to/module/autoload_register.php';
$foo = new module\Foo;
Again, these are NOT REQUIRED, but useful for telling a story of
re-usability outside the framework and/or module manager.
> Can we please streamline the autoloading story?
> Currently nearly all modules share the same autoloading scenario,
> which is PSR-0 in a subdir of module's dir.
This is true. But because we don't enforce the module structure, it's up
to the module class to tell us how to autoload; module developers do not
_need_ to follow PSR-0. Additionally, the StandardAutoloader is
substantially slower than using a classmap (even when having
namespace/directory pairs), and if you have a classmap, this will be a
faster solution.
> I think it would be better if a module loader handled that.
> Or ModuleAutoloader?
We have good autoloaders for this already, and Evan and Rob did some
great work with the AutoloaderFactory already to make this simpler.
If you use the AutoloaderFactory, and pass an autoloader class that has
already been loaded, it will simply _add_ configuration to it. Thus, the
following works:
AutoloaderFactory::factory(array(
'Zend\Loader\ClassMapAutoloader' => array(
__DIR__ . '/autoload_classmap.php',
),
));
This will _add_ the classmap in our module to an existing
ClassMapAutoloader if one already exists, or create a new one otherwise.
During development, you may want to have your autoload_classmap.php
empty at first, so that you don't need to worry about populating it
until your class structure is finalized. In that case, the following
will work:
AutoloaderFactory::factory(array(
'Zend\Loader\ClassMapAutoloader' => array(
__DIR__ . '/autoload_classmap.php',
),
'Zend\Loader\StandardAutoloader' => array(
'namespaces' => array(
__NAMESPACE__ => __DIR__ . '/src/' . __NAMESPACE__,
),
),
));
Like the previous example, if another StandardAutoloader has been
created, then this will simply _add_ configuration to it. No new
autoloader.
Once your class structure is finalized, you can generate your final
classmap, and remove the reference to the StandardAutoloader -- but that
would be a microoptimization at best.
By taking this approach, we don't have to worry about module structure;
the module developer can do that. If they don't want to put code in a
"src/" tree, they can register the StandardAutoloader differently, or
use an entirely different autoloading system. This leaves the framework
code simpler, and puts the onus on the developer to choose a sane
strategy.
What we _could_ do is provide the above in a base Module implementation.
> For example: adding a module to an application, adds a path to
> ModuleAutoloader PSR-0 folder stack:
> + /modules/ModuleA/src
> + /modules/ModuleB/src
>
> If a classmap exists, a ModuleClassmapAutoloader adds paths
> to its stack:
> + /modules/ModuleA/.classmap.php
> + /modules/ModuleB/.classmap.pho
What you describe here is exactly how what I describe above works.
--
Matthew Weier O'Phinney
Project Lead |
[hidden email]
Zend Framework |
http://framework.zend.com/PGP key:
http://framework.zend.com/zf-matthew-pgp-key.asc--
List:
[hidden email]
Info:
http://framework.zend.com/archivesUnsubscribe:
[hidden email]
Locked
