-
Notifications
You must be signed in to change notification settings - Fork 9
Various cleanup #27
base: master
Are you sure you want to change the base?
Various cleanup #27
Conversation
$bcrypt = new Bcrypt(); | ||
|
||
if ($serviceLocator instanceof AbstractPluginManager) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed this check because this is not needed. "bcrypt" is inside a plugin manager so the service locator will always be a plugin manager. People that want to add a new BcryptHandler will add it in the handler plugin manager so this is no problem.
The |
@@ -28,14 +28,9 @@ class BcryptFactory implements FactoryInterface | |||
*/ | |||
public function createService(ServiceLocatorInterface $serviceLocator) | |||
{ | |||
$config = $serviceLocator->getServiceLocator()->get('BaconUser\Config'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This produces an error for me in PHPUnit:
Fatal error: Call to undefined method Zend\ServiceManager\ServiceManager::getServiceLocator() in /Password/Factory/BcryptFactory.php on line 31
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$serviceLocator is not a plugin manager then... It should! So lileky the object that ask this bcrypt factory uses the global service manager instead of using the proper plugin manageR.
There are a various other things I've seen but I'd like to discuss with @Ocramius and @DASPRiD before changing it:
There are a lot of factories scattered at different places in the code. For instance, "Password" have a subfolder "Factory", while Repositories factories are in the top-root "Factory" folder. I'd like if we had somehting cohernet on that. As the module is pretty specific and should not end with a lot of new features everyday, I'd be in favor of creating a Factory folder inside "Repository" too as well in "Options". The only one that makes sense to stay at top level is "ConfigFactory".
There is a "allowed_login_states" option, but I can't understand it. It's not used across the code base, adn the name is a bit misleading. I think it should be called "allowed_user_states" and be used either in the User entity before setting the user state, or somewhere in a service, throwing some kind of "InvalidUserStateException". But even, I don't really like this method. I think the user state should belong to the entity class and be defined there. There are not really "options", they are part of the entity's logic. So maybe we could remove it and doing something like that in the User entity:
And people shoudl just extend the User class, and setting the allowedStates property.