David, > This really is nice, I like seeing the old FormWizard becoming more > flexible and reusable. But not what I intended.
I think your intent is the same we had with refactoring the wizard -- allowing access to the view state inside the wizard steps. > The new WizardView still handles a list of forms to be rendered. What I > proposed is completely moving away from the FormWizard...meaning instead > of passing a list of forms a ViewWizard should get a list of views. Each > view could then a) save/restore its state using some storage api and b) > tell the wizard about its state (step is complete) to allow moving to > the next step. That's already possible with the new API since *it is now a view*. So I don't see a good reason to add another level of abstraction to the wizard system further moving away from the main use case -- providing the ability to implement multi-step view rendering. > Using this approach the FormWizard is just a ViewWizard containing of > only FormView's. Besides that you could even use a ViewWizard as a step > inside a ViewWizard (recursion), but thats probably scary to handle ;-) > Anyways the views itself (=steps) would have much more control about > what happens and how the data is processes. What is there more to know about how the data is processed in the new WizardView than the data already provided due its nature as a class-based view? Jannis -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
