This is a classic and long-standing problem with web app development which is not easily solved, and it's not at all unique to CF. I say that, to help you broaden your perspective if you may go searching for solutions or explanations.
(I hit ctrl-S out of habit, while writing at this point, because I had to go check something else out, and it posted my reply. I did not mean to post that alone as my answer. I will come back and finish my answer in a moment. I'm reporting this for any who got emailed the reply, in case they come back and might see this before responding to me.)
I try here both to answer your question and offer more background on the challenge and some other solutions you may consider.
And I know your simple question is whether the a redirect can take form data with it (it cannot, if by redirect you mean a CFLOCATION or its equivalent). And I know you said you're "not a programmer". This is going to need a programmer to solve it, and even then different programmers would indeed approach the solution different ways, some far more elegant than others.
Background:
If you look around you'll find discussions of such topics "concurrent users", concurrency (which has still broader applications), "last write wins" (also broader than just web apps), and so on. I mention those variations on the topic because you'll find various "solutions", including ones that talk about "locking records" at the DB level--but that won't work, because in the case of a web app, you're not really talking about 2 requests trying to update the same record AT THE SAME TIME (like within milliseconds, which the DB will try to accommodate).
Instead, this is about the possibility that 2 users may fill the same form to modify the same record, perhaps minutes apart...but the problem is that while user A has loaded the record's data and is filling in a form to change it, user B has already come and gone editing the record more quickly. The problem is that user A will OVERWRITE the record, putting in whatever they changed, potentially LOSING whatever change user B may have put in. (That's why it's referred to often as "last write wins".)
Again, the problem has dogged web apps since their "dawn of time" (mid-90s).
Your proposed solution: "lock" and "logoff"
So back to your challenge, and your seeming solution: before I propose an alternative, I do have a couple of concerns with your proposed solution. First, it seems you are saying you would try to "lock" all users while another is "logged in", right?
(It may be helpful to clarify some terms: you would more likely BLOCK the other users somehow, wanting to not let them even TRY to get to this form? You may refer to this as "locking them out", but "lock" has some specific meanings that could get confusing if used for what you mean here. Indeed, some solutions regarding this problem may talk about "locking" records in the database manually somehow. That's another solution but not likely the best for a we app, Second, you refer to the user being "logged in" to the form, but all the users are "logged in", right? You really mean simply the user already "using this form", right?)
So it seems you plan to "block" other users from "using this form" while some other user is already using it. That could work, but it's clumsy. As you say, you then have to deal with how to handle the user already on the form, if they take "too long". Both of those could get ugly, and there may be a better solution.
Your question: saving form data on redirect
But back to your specific question, it sounds like you were hoping you may more simply just "save off" what the user had posted in their form.
You COULD do that, yes. Not on the page you "redirected" to, but instead on whatever page is indicated in the "action" attribute of the "form" tag of the form in question, then I suppose you could "redirect them" to the "home page", by which I assume then when they go to the form again you'd somehow planned to show them the data they had started to put in.
Again, you could do that, but that too could get clumsy.
An alternative solution: Ajax
Some good news is that advances in tech do afford possibilities to implement better solutions. First and foremost may be Ajax: put simply this is the ability of javascript-based communication to the server (in the "background" of the page as it appears to the user), before submitting changes.
An Ajax call could be made on the page to see if the data has changed, and if so, could do any of many things, like warn the user that the data has changed, or even perhaps offer to help show the changes relative to what the user now has on screen. It could do that either on submission, or as people advance to a given field, or via a button they click to check, or every seconds, or even via a constant communication channel (called "web sockets") that would be setup via javascript between the form and some background CF process.
To be clear, none of these approaches (to have a form check if its data has changed) is not a built-in feature of CF. A programmer really would need to do this, and that would need to be not just a CF programmer but one with familiarity with Ajax (which means some javascript-based library, such as jquery or others).
Your situation is made even more challenging because it's a grid, where potentially MANY records are involved (any of which may be changed by either user in our scenario--and by any number of users at the same time, of course). But it doesn't really make it that much harder to solve, once one solves it. (Do you know if that grid is created via CFGRID, or some other approach? That could affect your options.)
One might wonder, after "all these years", why there's there's no built-in feature in CF to "handle this". The problem is that if it WAS added, it would be based on such a javascript framework, and an army of experienced developers would cry out that "you should never use CF's UI features" and "Adobe shouldn't be holding the hands of every CF developer".
There may well even be some hidden gem feature of CFFORM or CFGRID processing that DID try to handle this. I don't recall there being one. Someone may chime in with one, but again others would then assert "don't use that". Only you can decide what's best for your needs.
There may also be some existing alternative CFML user interface library that tries to handle this for you. There have been many over the years. Again, I can't recall if any helps solve this specifically, but one or more may.
And again, since this is really NOT a specific you may also find discussions of how to solve this using Ajax solutions that may even be built into one of the JS frameworks.
Summary:
Perhaps someone will chime in with knowledge of such existing solutions.
I don't l know if they will read all I wrote. I don't l know if you will. I know it's a lot to take in, in this day when people want twitter-level answers. But if there was a twitter-level solution to this problem, you wouldn't be in the pickle that you are. And since, again, your need is NOT AT ALL unique, I thought this worth elaborating a bit, in case others may find the discussion in the future.
But I know you said also you're not a programmer. That will make it tough for you to implement any solution, I'd think. There are folks available to help with such coding. I list over a dozen of them as a category of my CF411 site, specifically at http://www.cf411.com/cfappdev .
I hope something I've shared helps, But I do hope others may chime in with other or more specific solutions or insights for you.
/Charlie (troubleshooter, carehart.org)
7
Replies
The form page has set fields for each row, but the numbers of rows are dynamic. The update loops through the form when submitted.
AdChoices