ZF-Commons/ZfcUser — pull request #264 by tomphp (2013-03-13 21:23:59+00:00)
Title: Refactor: Separation of controllers and removing knowledge of post vars at authentication level

This PR contains no changes to the features of ZfcUser. It is just the start of some refactoring of the module.

This PR doesn't provide much improvement as it is just the very start of the process, I have issued it however to make sure I'm on track as I don't want to spend days/weeks doing a full refactor then have it rejected.

What this refactor contains
====================
1. Seperation of the controller into separate controllers
-------------------------------------------------------------------------------
Currently the single `UserController` is pretty hard to follow and contains a lot of code and also member variables which only really apply to single actions.

In the PR I have split it into 3 controllers:
* `AuthenticationController` (with login, logout & authenticate actions)
* `RegistrationController` (with the register action)
* `UserController` (for user management with changeEmail & changePassword actions)

What I am doing next is breaking down the long actions into protected methods to make the actions more concise and obvious, at the end of this process I expect to move these methods out of the controllers into appropriate and testable classes (such as the User service class).

Once the actions are tidy and the logic moved to the appropriate place it may seem reasonable to merge the controllers back to a single one if wanted....or not ;-)

So far I have only started with the `AuthenticationController`

**Pros of these actions**
* Simpler controller actions
* Moving of work into the model
* Less code to be parsed by php per request as only the appropriate controller class will be loaded
* Easier to test

2. Removed knowledge of post variables further down the authentication process
---------------------------------------------------------------------------------------------------------------------
The current authentication method adds the `Request` object to the `AdapterChainEvent` then in `Authentication\Adapter\Db` the requested identity and crediential are fetch out of the post variables via the request.

I don't think there should be any knowledge of post variables this deep in the process there for I have now made it so that the post variables are fetched in the controller (maybe these should even come from the form object?) and then the are set as parameters in the `AdapterChainEvent` via `setAuthenticationParams()` which is then used in the `Authentication\Adapter\Db` class.

**Pros of this action**
* Removing knowledge of HTTP at the authentication level
* Easier for testing
* Looser coupling allowing for more extensibility

----------------------------------------

So these are just 2 things I have started on, I would very much like to push on further but I thought I'd issue this PR to get a go ahead or stop at this point.

I very much look forward to a response.