I’m switching from Zend Framework 3.0 to Laminas.
In ZF3, the Doctrine 2.0 settings work fine, but in Laminas, the Entities report an error when I use EXTEND when declaring a class.
If I don’t use EXTEND because it is a class that I don’t need, then everything is fine.
If I use it, Doctrine won’t find the extended class.
It’s like NAMESPACE doesn’t work well under Doctrine.
I have the understanding that the getAutoloaderConfig () function does not run in MODUL.php. Is it possible?
This is the first time I’ve tried ZF3, but since I was afraid that Laminas is new, I’d switch to this one right away.
Everything is fine under ZF3, except it is not working properly in Laminas.
Composer is a preferred way for handling your autoloading:
If you used new skeleton application as a basis for migration, then yes, it is possible that Module::getAutoloaderConfig() is not used. You would need to enable loader usage in configuration as it is turned off by default:
Fatal error : Uncaught Error: Class ‘vnw\Entity\AbstractObject\AbstractObject’ not found in /Users/macinosh/Sites/laminas/vendor/vnw/Entity/Internationalization/Taxes.php:10 Stack trace: #0 /Users/macinosh/Sites/laminas/vendor/doctrine/persistence/lib/Doctrine/Persistence/Mapping/Driver/AnnotationDriver.php(234): require_once() #1 /Users/macinosh/Sites/laminas/vendor/doctrine/persistence/lib/Doctrine/Persistence/Mapping/Driver/MappingDriverChain.php(107): Doctrine\Persistence\Mapping\Driver\AnnotationDriver->getAllClassNames() #2 /Users/macinosh/Sites/laminas/vendor/doctrine/persistence/lib/Doctrine/Persistence/Mapping/AbstractClassMetadataFactory.php(90): Doctrine\Persistence\Mapping\Driver\MappingDriverChain->getAllClassNames() #3 /usr/local/zend/var/plugins/doctrine2/zray/DoctrineOrm.php(351): Doctrine\Persistence\Mapping\AbstractClassMetadataFactory->getAllMetadata() #4 /Users/macinosh/Sites/laminas/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php(164): Sake\ZRayDoctrine2\DoctrineOrm->entityMapping(Array, Array) in /Users/macinosh/Sites/laminas/vendor/vnw/Entity/Internationalization/Taxes.php on line 10
I do not understand.
I do not use composer.
I need to put NAMESPACE to the Laminas configuration.
This was done by getAutoloaderConfig ().
Or I don’t understand something.
We do not support autoloading without composer anymore. Framework does not provide other means of autoloading for its components or dependencies.
I strongly urge you to adopt composer, which is now a standard way to manage dependencies and autoloading in php ecosystem.
I can guide you on how to setup autoloading with module manager, but it will not be an easy and convenient way. You would need to provide autoloading configuration by yourself for each and every component you use and bootstrap parts of the application each time before doing anything else. I’d rather spend the effort elsewhere.
Ok,
I try to add psr-0 autoload (vnw/ vendor/vnw/), but nothing happened.
I use Zend Studio.
I modified composer.json. (psr-0 settings added above line).
And i ran php composer.phar update.
And nothing.
What do I do wrong?
It is the default setting used in the skeleton application that I told you to change previously. Sorry for misunderstanding. You just enabled laminas-loader usage in module manager.
However it does not solve all the other inconveniences with the laminas-loader and module manager approach to autoloading. You solved immediate issue but I would recommend you to revisit composer only autoloading at some point.
Some suggestions for you:
psr-0 autoload you tried is long since deprecated. Psr-4 is preferrable. I linked it above
vendor/ folder should only have packages installed by composer itself
vendor/ folder should be ignored by version control system (.gitignore file for git). Ideally you can delete it and run composer install to get back fully functioning application
I would recommend you to manage installation if vendor/vnw/ with composer, let composer handle its dependencies and autoloading. If you commit content of vendor/vnw/ then common practice is to move such library into src/ or library/ folder and register composer psr-4 autoloading rules for each of such libraries.
modules/ directory does not necessary have to include MVC modules. When autoloading config is all that Module class provides then you can safely delete it entirely, along with the entry in the modules list, and depend on composer autoloading
when you use composer, you would want to move Module.php into module’s src/ folder so that Module class can be autoloaded by composer
Thank you for the information.
I’m not sure I understand everything, but it works.
Actually, I don’t understand that if I configure my PSR-4 module and update composer, what happens at the program level.
Since I don’t see any change, but the getAutoloaderConfig is running now.
@visualnetwork composer gathers autoload rules from composer.json files of your application and all installed dependencies then it generates autoloading code in vendor/composer/ folder. Go check it out. vendor/autoload.php is just a shortcut to that generated code. Generated code is registered with spl_autoload_register() to be called when php tries to use class that is not yet defined.
laminas-loader registers itself with spl_autoload_register() too, but it happens when you bootstrap the application. Module manager, event manager, many events are triggered and listeners fired. Modules loaded, laminas loader created and configured, then whole mvc application is bootstrapped. As you can see there are a lot more things happening.
Composer generated code is very lightweight and it is universal way to manage autoloading. Also, since composer manages all the dependencies it knows how to collect all autoload rules defined by dependencies. And it needs to do that only once, when you run the composer command.
@xerkus thanks for the information.
I am slowly beginning to understand.
I don’t understand why getAutoloaderConfig () is running now?
Why didn’t it run down before then?
After all, it doesn’t matter.
Now I know how to add my moduls.