Copy link to clipboard
Copied
I have a form that many people share. If more than one person uses it, their data is overwriting the next persons.
I am working on a new page that will lock all other users from being able to submit data if another person is "logged" on to the page.
The logged in user will get kicked out after three minutes of inactivity.
The concern is, you may update several of the fields, get interrupted by a phone call, then get redirected to the home page and lose your data.
If I have it redirect to the submission / processing page, will it take the form data with it, then I can send them to the home page?
Please keep in mind, I am not a programmer, so I know there are likely many more elegant ways to resolve this.
Thank you
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
Thank you all.
Charlie, sorry for the use of the work LOCK, you are correct, I am blocking other users.
This is an intranet for our department. There might be 3 or 4 users at the most on this page at the same time.
What I have done is, when a user first visits that page, a query is made to a table I created that stores the user ID. If another user is currently using the page, the forms Submit button will not display, instead they will see a message that another user is currently using the page. I have a scheduled task that will reset that user to 0 just over every 3 minutes, that way if a user simply closes the page, it is not left assigned to them.
What I planned to do was redirect the person on the page after three minutes of inactivity to the home page. If I redirect them first to the action page, will it submit their data? That would be perfect.
I understand this is not an elegant solution, but as a non-programmer, many of my solutions are not elegant.
Thank you
Copy link to clipboard
Copied
If you redirect the user to any page, including the action page, the data won't be submitted unless the action page is designed to accept URL parameters instead of or in addition to form data, and the URL parameters in question are included within the redirect URL. All that is basically a long and slightly more accurate way of saying "no".
Dave Watts, Eidolon LLC
Copy link to clipboard
Copied
Thank you Dave, that won't work then. The form page has set fields for each row, but the numbers of rows are dynamic. The update loops through the form when submitted.
Copy link to clipboard
Copied
Again, there are ways with Javascript to handle this much better, but I'm afraid the simple solutions you were considering will call lead to the user losing what they had entered.
I appreciate that for you, the need doesn't seem to warrant the time and expense needed to handle the problem more "elegantly". I just would caution other readers that the problem CAN be solved. But again it does (for now) take manual effort to prevent or protect or recover from the problem of such multiple concurrent updates by different users to a given page/set of records.
Copy link to clipboard
Copied
I think Charlie's reply is pretty good, if appropriately very broad and general. But to make this shorter, you will need to do the following:
a) use JavaScript to track user behavior and send modified values to the server,
b) devise a business rule outside of your database to determine what should happen after those modified values have been received by the server,
c) implement that business rule in CF.
Note that, if you're really concerned about conflicts, you'd need to do this whether the user explicitly submits the form or not. If you have two users who submit form data at the same time, and you're concerned about the potential for one update to overwrite another, you'd need to do (b) and (c). To handle (b) and (c), the best way I've seen to handle this is to have specific database fields for this: I like to use something along the lines of "UpdateUser" and "UpdateDate". If two users select the same record to update at around the same time, your update code could determine whether there's a conflict between UpdateUser values, and you could figure out what kind of response you want when the second update query would normally run. For example, if you had two users updating the same record, but one user is updating one field and the other user is updating another field, you could have code show the second user that the first field has been updated to a different value already, and only update the second field. This would be significantly more complicated than the normal flow of select/update that most web applications have.
Dave Watts, Eidolon LLC
Copy link to clipboard
Copied
ctreeves, it is unclear to me what your requirements are.
1) You state
user will get kicked out after three minutes of inactivity.
and
The concern is, you may update several of the fields, get interrupted by a phone call, then get redirected to the home page and lose your data.
as separate requirements, but they are one and the same. The second follows from the first.
2) Following a period of inactivity, is a user logged out of the form page or out of the entire application?
3) Suppose user A gets logged out while busy on the form page. Suppose User B then arrives at the form page. Do you want user B to resume filling a form that is pre-filled with A's data?