In Steps 2, the subprocess selection form is visible according to the process.
I am submitting the process first & then load the subprocesses accordingly. This part is done using GET HTTP method. If someone can suggest a better method, it will be amazing?
In Step 3, I am uploading a file and capturing a couple of info from the CSV file.
Now I want to store this data and use it in the next form.
Currently I am using JSON files but the problem is that the data doesn’t get deleted automatically if someone reloads the page.
I not getting a good method to temporarily storing the data such that if someone refreshes the URL, then the temporary data stored should automatically get deleted.
NOTE: I need to store at the data from step 1 to step 4, as all the data entered from step 1 to 4 needs to be stored in 1 model class itself
Take a look at the form wizard component within Django formtools.
Regarding the file uploads, that is something you’re going to need to manage yourself. What we do is run a process once a week to cleanup “abandoned” uploads.
We use cron. You can use whatever you like. (For clarity, this is done outside of your Django wsgi process.) We also have scheduled processes that run from Celery Beat.
Regarding the file uploads, that is something you’re going to need to manage yourself. What we do is run a process once a week to cleanup “abandoned” uploads.
This technique worked for me but I am facing an issue where one of the steps of the form has “Cascading Dropdown/ select”.
Now I got the answer for how I can create a “Cascading Dropdown/ select” in this thread:
On using django-formtools I am unable to use the option as I am unable to write a view functions separately for dealing with the particular form and unfortunately most of the solutions found by me requires it.
Is there any way to do it using djando-formtools?
If not can you please suggest some alternatives?
On the form for a page, you have a dropdown that ends up calling a different view to retrieve the dependent values. That extra view doesn’t need to have any relationship to the page invoking it.
As long as you can render the appropriate widget in the form, this will work.
(Note, I’m not a fan of the particular way in which that solution renders and manages the select field. It’s not that it’s “wrong”, it’s just not the way we choose to handle it. We prefer to let Django render the select field like any other select field, and allow the event handler to build the url parameters from the selected element.)
Ok but since I am using django-formtools, how to “have a dropdown that ends up calling a different view”?
I am unable to understand, can you please elaborate it somewhat?
If you’re using formtools, it’s the WizardView (or a subclass).
Within those pages, you have some JavaScript. That JavaScript has an event handler to call a function whenever a particular select box is changed. When that event handler executes, it does an AJAX-style GET to a different view from the view mentioned above. The purpose of this second view is to create the list of options to populate the dependent select list.
The point here is that this second view does not alter the overall flow of events. By making this an AJAX style call within the page, you’re altering the current page. (You’re not submitting the page to retrieve the next view from the wizard.)
This logic applies regardless of your usage of formtools.
You can either create one view to handle all dependent select lists, or you can create multiple views - each handling only one select list. That choice is up to you. But the choice between these two options doesn’t fundamentally affect the overall design outlined above.
