Zf3 & ZfcUser 3 support#27
Conversation
|
Thanks for the PRs Daniel, just wanted to let you know I've seen them and will have a look over as soon as I can with a view to a merge :) |
|
@mtudor is there anything I can do to get this PR merged/released? Would a code review from my side help? |
|
Hi @lenada - appreciate the offer and the intent "not to stress" :) I might take you up on it but give me a little time to do an initial skim over first just in case to save you any wasted work. Just getting my dev environment back up (had to reinstall) and then I'll get onto this (hopefully in the next 7 days). Please do feel free to drop me a prod if things go quiet on my end, though I will try to make sure they don't! ;) |
|
@mtudor dropping you a prod 🤓 |
There was a problem hiding this comment.
@Danielss89 good work 👍, see minor comments below
| <?php | ||
| // Generated by ZF2's ./bin/classmap_generator.php | ||
| return array( | ||
| 'ZfcUserImpersonate\Module' => __DIR__ . '/Module.php', |
There was a problem hiding this comment.
I suggest moving the current Module.php to src/ZfcUserImpersonate/Module.php and adding a /Module.php containing
<?php
require_once __DIR__ . '/src/ZfcUserImpersonate/Module.php';That way we can omit the classmap in composer.json and the module becomes fully PSR-0/4 compliant.
There was a problem hiding this comment.
Yep - I'm up for this. Do you think we ought to go PSR-4 and change the base directory from src/ZfcUserImpersonate to just src/. Is that more in-line with the standard these days?
If we move the files, a second PR makes more sense I would think.
| { | ||
| public function getConfig($env = null) | ||
| { | ||
| return include __DIR__ . '/config/module.config.php'; |
There was a problem hiding this comment.
When applying the require_once approach, as described below, /../../ need to be added to the config file include.
There was a problem hiding this comment.
Pending the decisions on PSR-0 / PSR-4.
|
Just finishing off some critical day job stuff and then will aim to jump on this - thanks for the prod :) |
mtudor
left a comment
There was a problem hiding this comment.
A few small tweaks and I think we're good to go. Thanks for your work on this @Danielss89, and for the review @lenada :)
| <?php | ||
| // Generated by ZF2's ./bin/classmap_generator.php | ||
| return array( | ||
| 'ZfcUserImpersonate\Module' => __DIR__ . '/Module.php', |
There was a problem hiding this comment.
Yep - I'm up for this. Do you think we ought to go PSR-4 and change the base directory from src/ZfcUserImpersonate to just src/. Is that more in-line with the standard these days?
If we move the files, a second PR makes more sense I would think.
| { | ||
| public function getConfig($env = null) | ||
| { | ||
| return include __DIR__ . '/config/module.config.php'; |
There was a problem hiding this comment.
Pending the decisions on PSR-0 / PSR-4.
| use ZfcUserImpersonate\Module\AbstractModule; | ||
|
|
||
| class Module extends AbstractModule | ||
| class Module implements ConfigProviderInterface |
There was a problem hiding this comment.
So, to clarify as much for me as anyone (but also as a sanity check), now that we don't have any closures in the service and controller config, we no longer require the getControllerConfig(...), getServiceConfig(...) and getViewHelperConfig(...) functions that the AbstractModule provides. Therefore you've essentially removed the AbstractModule functionality (it's based on our https://github.com/tccltd/TccAbstractModule, btw, and we tend to use it for getting up and running quickly). If I've understood the reasoning correctly, I agree that for a vendor module we should aim to be optimised and so the removal makes sense. If I understand correctly as well, we now have the benefit that all of the config is cached?
Finally, we're dropping autoloader related stuff because nowadays composer should really take care of all of that?
| 'zfcuserimpersonate_adminController' => \ZfcUserImpersonate\Factory\Controller\AdminControllerFactory::class, | ||
| 'zfcuser' => \ZfcUserImpersonate\Factory\Controller\UserControllerFactory::class, | ||
| ) | ||
| ); |
There was a problem hiding this comment.
This all looks great, including the two new factory classes. I've been wanting to do that for a while so really appreciate this change!
| 'zfcuserimpersonate_module_options' => \ZfcUserImpersonate\Factory\Service\ModuleOptionsFactory::class, | ||
| 'zfcuserimpersonate_user_service' => \ZfcUserImpersonate\Factory\Service\UserServiceFactory::class, | ||
| ), | ||
| 'view_helpers' => include('viewhelper.config.php'), |
There was a problem hiding this comment.
***** Make a decision on this new style of config separation *****
| use Zend\ModuleManager\Feature\ConfigProviderInterface; | ||
| use Zend\Mvc\MvcEvent; | ||
| use Zend\View\Model\ViewModel; | ||
| use ZfcUserImpersonate\Module\AbstractModule; |
There was a problem hiding this comment.
This can go now, right (AbstractModule has gone)?
| ), | ||
| ), | ||
| ), | ||
| ), |
There was a problem hiding this comment.
I wonder if we ought to leave this in module.config.routes.php and require it as you have done with controller, service and viewhelper configs?
| @@ -7,21 +7,14 @@ | |||
| */ | |||
|
|
|||
| use Zend\Authentication\Storage\Session; | |||
There was a problem hiding this comment.
No need for this use anymore either right?
| @@ -11,15 +11,7 @@ | |||
|
|
|||
There was a problem hiding this comment.
Can get rid of the use statements above now these are handled in the factories?
| @@ -10,26 +10,7 @@ | |||
|
|
|||
There was a problem hiding this comment.
Can get rid of the use statement above now this is handled in the factory?
You should probably tag a new major release as this is breaking for people using ZfcUser 2 or 1