I am building large forms across several pages (and several databases) which sits under one app. The responses from the user will be saved in rich text editors, and there will be a dropdown box for the user to indicate if their response is complete or not applicable. When the user selects an option, the text editor’s box will become disabled to avoid any accidental changes (but also to use in future development where I can determine to what extent how many of the fields are marked as ‘complete’). This disabling of the form will be done via a condition on the text editor.
Now, initially I was planning to create a drop down for each of these responses across the app (about 150 or more in total). This means that there will need to be a field in the corresponding database tied to that specific response to for the app to know that is complete or not. So lots of dropdown related ‘status’ fields in the database and these will need to be programmed into the editor and a ‘thing’ created when ever a save would be initiated.
Is there a way to instead of creating a ‘thing’ in the database for each of these dropdown values, that the user selects the value from the options, and then this value isn’t only held in place (despite page refreshes), the text boxes can be marked as disabled via a conditional because if this value being selected, and form progress being calculated?
The standard practice if we want things to stay on page refresh is to create a thing in the db. Else it will delete on page load.
Maybe you could share a screenshot of your setup to understand further?
Yes. You can save the variables using cookies in the user’s browser. Don’t know if it’s the best solution but it is doable. There are some plugins for this, try a search here in the forum.
If you don’t want to use cookies (which you won’t get any data from if a user prevents you tracking them), I’d just think about how to make your data structure as lightweight as possible.
Instead of creating a new ‘response’ for every individual form for every user, why not have:
a list of master forms/questions in the database (so one for each richtext input)
a ‘completed forms’ field on your user, which is just a list of ‘forms’
anytime a user completes a form, you add the master form in question to this list. Then if you want to see if a user has completed a form, you check if the form in question is in the list. Forms not in the list can be assumed to be incomplete.
In this way you don’t need to create any extra data objects; you’re only storing a relatively small number of unique IDs (for the completed forms) on each user.
The cookies option the others mentioned should work fine with the caveat that Matt mentioned. I think this is the only way if you want to avoid saving to db.
What I would do for a form of so many questions as yours is create a data field on the current user of type number and increment that depending on the question completed. So if question 10 is done it increments by one and a conditional formatting is set to prevent modifications on the question that was completed.
This way you can use the field to calculate progress as well. You do have to make changes to a thing every time but a custom event should make it easier. And if all the questions are in a rich text editor you could also make it a reusable element and ease things more.
The app is actually layered with other complexities such as audit tracking whereby the app will save a historical copy of the previous answer in a field whenever the user goes into change it (so they can in effect scroll through all the changes they’ve made since the start). The current response, however, is pushed to an API where this information is shared elsewhere. There are also collaboration elements too so other users can see and edit the same form.
The structure I have at the moment I wouldn’t say is lightweight, but that’s really because the app is a set of forms, with a few resource heavy features, the ‘audit’ of answers being the main one.
Yes, the cookies thing won’t work, as Matt has mentioned. Too unreliable for quite an important feature.
This is a good idea though, but will it appear as a dropdown on the main page as above, or is an automated thing where the question will trigger an increment when it detects answer in a field? Otherwise it won’t know when an answer is truly ‘completed’.
The only issue with this is that if it simply works as a ‘ticker’ the admin won’t be able to do a search to bring up all the questions that had ‘completed’, or ‘not applicable’ assigned to it which they’ll be able to do if I implemented a status drop down as above. I’ll also be able to push this data via an API and tell it to only push those questions with ‘completed’ assigned to it, for example. There are definitely benefits from creating a new thing for this, but adding this in means create 000s of new fields.
Unless this can be implemented via your suggested method?
I will need to think more on this, but one idea off the top of my head is to keep three list data fields on the current user for the menu options. Completed, not applicable and incomplete. Data type of number again.
And when the user marks it as not applicable for example it adds it to the list of not applicable ones. That way the admin can search for those questions within the relevant list.
You will have to track the question number though for this and ensure that the order doesn’t change later. You could maybe use another field instead of a number.
These fields would be in addition to the previous number field mentioned earlier. Let me know if this might work.
Thanks, I will give it some thought. It’s hard to try and have the foresight to know whether a structure will be useful for any future features waiting to be implemented or ‘nice to haves’ as there might be limitations with a particular approach.
Just if I was to think about this proposed idea quickly, assigning the three options to the user might mean that when collaborative users also view the same forms they will not be assigned any of these statuses to their own account in the db. In other words, the status of these responses won’t be ‘centralised’ and held in the app, but rather against a user’s account. If that user then deletes his account, or disconnects from that project, he takes that data with him (or its deleted entirely). As these projects often span years, this becomes something worth keeping in mind.
