Closed cpattersonit closed 6 years ago
You can subclass and specify a different one if you like.
This isn't meant to be dismissive -- the point of class-based views is you don't have to accept the defaults, and can subclass/override/customize to your heart's content. Learning how to do this (the documentation provides examples), and doing it when you want different behavior, will be the key to getting what you want out of django-registration.
Yes, that is what I am currently doing with this view, and I do it often to extend the functionality of dependencies. The reason I opened the issue is because you provide a public success_url attribute (with a default of None) as well as a public get_success_url() method that overrides any success_url that's passed. If a public attribute is provided, I think it should be able to be used on its own without the need to also override the method in a subclass; otherwise the attribute should be private.
You have a lot more experience than I do, and I can imagine how much work it is to maintain multiple open source projects. I am currently using two of yours everywhere, and I've found your code helpful as a reference for best practices I try to adhere to. I'm just trying to provide constructive help along those lines.
But a class-level property allows "anonymous" overriding, like in
TemplateView.as_view(template_name="my_template.html")
But with the get_success_url
method we have to subclass the view in our packages, when the only thing we need is to set these properties.
The get_success_url() method in the HMAC RegistrationView has a hard-coded view name, which prevents the passing of a different success_url attribute (such as a namespaced one) to the view: