Infinite Recursion possible in 2.4

[dave-v]

We have a condition_dict containing the following function:

def need_further_steps(wizard):
    data = wizard.get_cleaned_data_for_step("0") or {}
    if data.get("no_invoices_needed", False):
        return False
    return True

The call to WizardView.get_cleaned_data_for_step then calls WizardView.get_form, which used to reference self.form_list, but the following commit changes this to self.get_form_list(), which then calls the user-supplied condition_dict functions, which then calls our need_further_steps function above, which calls WizardView.get_cleaned_data_for_step, and so on ad infinitum.
533a830

Perhaps our custom condition function is bad, but it doesn't seem too unreasonable?

[claudep]

@stuaxo, @schinckel, any idea about how to avoid that regression?

[schinckel]

I think I’ve had similar issues. I’ll try to have a look later tonight to see how I got around it.

[schinckel]

Okay, I've found the similar problem I came across. I think it's the "same" problem, just a different approach.

I had code in get_form_list that needed to see cleaned data from other steps, which triggers the infinite co-recursion.

My workaround was to get the raw data instead, and build up that form and get the cleaned data that way.

We should think about either/both a way to handle this (getting cleaned data from other steps in condition_dict callable), and/or documenting the problem.

[schinckel]

Ah, looking at the code, it seems that whilst get_cleaned_data_for_step(step) doesn't use get_form_list(), it uses get_form, which does.

As an aside, I think for consistency, get_cleaned_data_for_step should use get_form_list.

But that doesn't solve this problem (it just moves it to a different place).

[schinckel]

I wonder if it's possible to use a generator that retains knowledge of previous steps: it should be possible for condition_dict to refer to previous steps, but not subsequent steps.

Let me see what I can get to work.

[stuaxo]

Maybe get_cleaned_data_step could be behind lru_cache with maxsize None.

[violuke]

We're also having the same issue

[DJJacobs]

Experiencing the same issue upon update from 2.3 > 2.4. Reverting back to 2.3 for now. Following for updates...

[violuke]

The fix of #168 has caused this problem. My understanding is that you should be using the conditiion_dict to vary which steps are in the wizard and which are not. I can see why overriding get_form_list() would seem like a nice alternative (and maybe simpler to use), but by changing get_form() to use get_form_list() and solve the request of #168, this makes it impossible to have conditions which look at prior form steps as part of their conditions and therefore breaks what is probably one of the most common use-cases of this package.

My opinion is that 533a830 should be reverted as it tries to allow the same problem to be solved in a new, previously-not-possible, way and breaks the original way of solving the same problem that's been part of this great package for years.

Thanks for your help, we've also had to pin 2.3 due to this being a breaking change for our use of the package.

[spapas]

I have a different opinion on this. By being able to override the get_form_list you have complete freedom on the list of forms you're going to display in your wizard. See here some example code from a project where a wizard is created dynamically based on some configuration (taken from the PR_ACTION list of dics):

class PilotRequestActionView(..., SessionWizardView):
    ...

    def get_form_list(self):
        form_list = OrderedDict()
        action = self.kwargs["action"]
        has_form = [x for x in PR_ACTIONS if x["code"] == action][0]["has_form"]
        if has_form:
            form_class_str = (
                "PilotRequest"
                + "".join(x.capitalize() for x in action.split("_"))
                + "Form"
            )
            form_class = getattr(forms, form_class_str)
            form_list[action] = form_class
        form_list["submit_req"] = forms.PilotRequestSubmitForm
        return form_list

So I can do something like

path(
        "act/<str:action>/<int:pk>/",
        views.ActionView.as_view(),
        name="req-action",
    ),

in my urls and create different wizards.

I really don't think that something like that would possible using the condition_dict.