More flexibility for registration

[arodiss]

While securityController provides a possibility to override template used for login (via renderLogin() method overriding), registrationController does not offer such functionality. The used template is defined in action method itself, and so to override it I have to copy-paste whole method or inherit bundle.
From my POV it would be nice to separate template rendering as it is done in securityController
Thanks.

[stof]

If you only want to overwrite the template, use the template overwriting feature by putting it in app/Resources/FOSUserBundle/views/...

[topwebstudio]

If you need to override the action, for example you got too much logic to change there go ahead.
If you have only few lines to change why don't you do this:

class RegistrationController extends BaseController {

    public function registerAction() {
                // custom logic - add page title
        $this->addTitle('Registration');

        return BaseController::registerAction();
    }

[tiagojsag]

I'm stumbled upon a similar problem: in my case, I need to change the behavior of the registration process, not just the looks of it. In my scenario, the user register and gets created as disabled, and an email need to be sent to some admin that will later on approve the account using SonataUserBundle's admin interface.

To do so, it seems like I need to override the registration controller, the form handler, and the user manager (and lets see what else).

It's really nice that we can override the controllers, but in this case it seems pretty useless since a relevant part of the logic is done in the form handler and the user manager, both of which are private services, which makes it even harder to override.

Also, and I didn't research this thoroughly, so pardon me if I'm saying something awfully wrong, but the registration controller and registration form handler seem to be so specific that they can neither be used on their own nor reused for something else.

I have two suggestions: first, don't use private services.
Second: externalize the full registration logic to a separate service, that matches a RegistrationStrategyInterface. Those strategies would be given to the RegistrationController as config parameter. Right now I see two implemented: the default "register and you're done" and "register and get a confirmation email". If these two could be fit into a single file each, it would help people implement their own, without having to reimplement 50 services, and you might even receive some that could be merged into the bundle.

anyway, just my 2 cents.

[stof]

Replacing the form handler is possible through the configuration. And the form handler is a public service. We create an alias of the actual implementation (the default one being private)

And see #867 for the upcoming version of the logic. As you can see, the confirmation email logic is now handled by a dedicated listener. Your logic sending a mail to the admin would simply be a matter of writing your own listener hooking into the events.

[tiagojsag]

Well, I just finished taking a look at it, and it seems really easy to extend, specially when compared to the previous implementation. congratulations on the excelent job ;)

[ghost]

@tiagojsag, @arodiss: So any thoughts on this ticket after hearing from Stof? Should any of this be adapted or continued at all?

[vkartaviy]

Also you might be interested in view events that i provided in pull request #913 but it looks like repository owners not really like contributions from outside or just have no time to review the changes...

[tiagojsag]

For my implementation it was enough to avoid rewriting a bunch of code that could be reused. I did miss some additional data being passed to some events, but in the end I was able to make it work anyway ;) for me, this can be closed

[ghost]

@tiagojsag : what information would you like to see added to the events?

[XWB]

Several events have been added.