This repository has been archived by the owner on Dec 23, 2018. It is now read-only.
Split WizardView into WizardMixin, BaseWizardView and WizardView #34
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello
I started using the django-formwizard for a project where we use a CBV based tab navigation. I need to put a form inside a tab.
Using the current generic views, this works without any problem, by adding the generic FormMixin to my views. But django-formwizard doesn't really work that way.
In Django's generic CBVs, all views are split into a mixin, a baseview and a view. The mixin extends object and contains no rendering logic. The baseview contains the mixin and rendering logic, but no template output. The final view extends the baseview but adds template output.
In django-formwizard, the
WizardView
extendsTemplateView
directly though. This can cause multiple inheritance problems, when using the WizardView as a mixin to an existing class.I tried to add this behavior to django-formwizard. Currently it's just a quick change, for which I'd like to get some feedback. The changes don't break any existing code. In case other people think this is a good change, I'd add some documentation to it.
One thing that doesn't worke nicely, but can't be fixed without breaking existing code, is the
get_context_data
method. All builtin generic views only acceptself, **kwargs
as arguments, but django-formwizard acceptsself, form, *args, **kwargs
as arguments. This means that any standard-conform mixins on top of the formwizard break it.What do you think about those changes? Can they be improved further? Would you provide baseviews for all view extensions like the
SessionWizardView
?If the changes look good, I'll probably file them as a bug request in the Django bugtracker after some improvements.