Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Restore compatibility with ModuleManager #55

Closed
Ocramius opened this Issue Jul 17, 2012 · 8 comments

Comments

Projects
None yet
2 participants
Owner

Ocramius commented Jul 17, 2012

Since 0.4.0 we're using composer as a method to autoload all dependencies of DoctrineModule, DoctrineORMModule and DoctrineMongoODMModule. While this is quite practical, we can add an utility Module.php that either redefines or includes (or extends) the current logic.

Interesting approach would be something like

<?php
require_once __DIR__ . '/src/DoctrineModule/Module.php';
Module::setManuallyAutoloaded(true);

then in the actual DoctrineModule\Module class, which would implement Zend\ModuleManager\Feature\AutoloaderProviderInterface:

<?php 
    public function getAutoloaderConfig()
    {
        if (!static::getManuallyAutoloaded()) {
            return array();
        }

        // introduce logic to handle autoloading, eventually also for dependencies 
        // if possible (hard!)
        return array(/* actual stuff, only when needed */);
    }
Owner

Ocramius commented Jul 17, 2012

Also to be noted: since DoctrineModule, DoctrineORMModule and DoctrineMongoODMModule are the exception to ZF2's rule about the location of Module.php, we should add notes about WHY we did it in the code (for newcomers that may be confused)

@ghost

ghost commented Jul 17, 2012

Why not just simplify the process and move Module.php back to the "normal" location. Check for vendor/composer and if it exists don't register zend autoloaders. No reason to get fancy when a simple solution would work.

Owner

Ocramius commented Jul 17, 2012

@spiffyjr my point is that ./Module.php is the fancy location, where src/DoctrineModule/Module.php is the correct (standard PSR-0) one. I didn't do the change to make composer "happy", but just to be PSR-0 compliant, and therefore compatible with any third party PSR-0 autoloader such as Doctrine's, Symfony's, etc. If the problem was about composer only, I would just have kept the classmap.

I have to add that docs are needed for installation without composer.

@ghost ghost assigned Ocramius Jul 17, 2012

@ghost

ghost commented Jul 17, 2012

Yes, but Module.php is a ZF2 specific file so anything done in there won't apply to any other source. That's why I think it's OK for it not to be PSR-0 compliant.

Owner

Ocramius commented Jul 17, 2012

First of all, re-introduced compatibility with 58861a0

@spiffyjr I'd argue that ZF2's only requirement is to have class_exists('ModuleName\Module'). No other requirement is really needed, and the module autoloader is a clever trick used to achieve this result when autoloading is not provided (not this case)

Owner

Ocramius commented Jul 17, 2012

Docs have been added. What still remains is (eventually) autoloading through Zend\ModuleManager\Feature\AutoloaderProviderInterface and how to handle dependencies (if there is some).

I don't really know how we could handle all these dependencies without composer (and in a way that is smarter from what we had before and moved away from) right now. The docs I've added require the user to do a lot of manual work and non-trivial autoloading setup.

Will think about it, but I surely wouldn't include submodules again.

Contributor

superdweebie commented Jul 17, 2012

Personally I prefer Module.php PSR-0 compliant. It keeps composer.json shorter and cleaner, and the resultant autoloader is also shorter and cleaner. Module.php might be in a slightly non-standard location for ZF2, but it's not hard to find - and I think other third party modules will follow the same pattern over time because of the simplicity.

@Ocramius Ocramius added a commit to doctrine/DoctrineORMModule that referenced this issue Aug 9, 2012

@Ocramius Ocramius Restoring zf2 autoloading as of doctrine/DoctrineModule#55 384984d
Owner

Ocramius commented Aug 9, 2012

I'll close this one since ODM and ORM modules are now at least compatible with the ModuleManager. What still remains eventually is autoloading dependencies, but this is not our problem imo, and we know where it ends...

@Ocramius Ocramius closed this Aug 9, 2012

@gencer gencer pushed a commit to gencer/DoctrineModule that referenced this issue Apr 11, 2014

@beberlei beberlei Merge pull request #55 from stof/sql_filters
Added the support for SQL filters
89d0f26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment