Answers inline
On 26 November 2013 16:55, dennis-fedco <[email protected]> wrote: > *Question 1* > > I see a file called Module.php in a lot of PHP packages. What is it, what > does it do, and why is it there? Who calls it, and how and why does it > work? > Are there any hidden magic PHP methods or other packages that call it and > how? Doing short yet reasonable Googling I could not find a good intro and > thorough explanation of all that. > The ModuleManager uses the module autoloader ( https://github.com/zendframework/zf2/blob/release-2.2.5/library/Zend/Loader/ModuleAutoloader.php) in order to discover module classes. IIRC, that is handled in a listener attached to `loadModule.resolve` in the EventManager of the ModuleManager > > *Question 2* > > I see that some packages have two Module.php files. Example: BjyAuthorize > package: > > master/Module.php > <https://github.com/bjyoungblood/BjyAuthorize/blob/master/Module.php> > master/src/BjyAuthorize/Module.php > < > https://github.com/bjyoungblood/BjyAuthorize/blob/master/src/BjyAuthorize/Module.php > > > > I see that the first module is placed there as per recommended structure > of > a typical MVC-oriented ZF2 module > < > http://framework.zend.com/manual/2.2/en/modules/zend.module-manager.intro.html > > > , so I understand that it is there because it has been defined by ZF2 and > ZF2 has code that expects this Module.php to be there. It would not be > there > if ZF2 did not define it. Why would ZF2 create a module system that > provides > the need to duplicate this file, when most modules already have a > designated > placement for it elsewhere? > The only relevant bit is the class. One of the files you linked doesn't contain a class. The only reasons why `Module.php` still exists as a file in the root of some packages are: - modules.zendframework.com rejects submissions of github repositories without that file in that location - some developers don't use composer, and prefer having modules autoloaded by the ModuleManager, using the ModuleAutoloader > > *Question 3* > > The first Module.php I linked mentions that the 2nd Module.php is there to > support PSR-0. But PSR-0 has no mention of a Module.php file name what so > ever. So I understand that the name of "Module" has nothing special as far > as PSR-0 is concerned, and Module.php is there purely to respect > vendor\Namespace\ClassName paths, and is just like any other class. Is > that > correct? > There's a class only in one of those 2 files, and it's the file respecting PSR-0 > > *Question 4* > > What happens if I delete the master/Module.php only and keep the other one > and restructure my code to work using some kind of my own custom > configuration? What is that I will break exactly? > Nothing will break as long as you guarantee that your Module class can be autoloaded. > > *Question 5* > > what happens if I delete the master/src/BjyAuthorize/Module.php only, and > keep the other one, and restructure my code to work using some kind of my > own custom configuration? What is that I will break exactly? > > Since the Module.php in the root of the repository doesn't contain anything, things will fall apart. If you copy the contents, it should work as long as autoloading works. > *Question 6* > > ZF2 by default creates Application/Module.php and no other Module file. > Does this mean that ZF2 module system is NOT compliant with PSR-0? This > can't be so, so why did ZF2 create such a module system to cause > duplication > necessity in some cases when there was already an established PSR-0 > standard? > > PSR-0 actually came out after the module manager was complete. The Module "convention" (which is fully optional nowadays, as I've already stated before) was (still is, for some people) the fastest way to allow quick discovery of module classes with the least possible amount of stat calls. The ModuleManager can't assume anything about a module except the possible location of the Module class if it cannot be autoloaded. That allows the ModuleManager to load any Module regardless of the convention in use, which is very powerful when a module doesn't provide autoloading or acts as a glue layer to a legacy library that maybe doesn't even have the concept of "autoloading". If autoloading is already in place, all the module loading dance is not a requirement. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
