Hello,
I need some advice. I have a form that has data from 4 different tables and about 10 values to save and keep until the form is finally sent.
Where would you save the 10 values (all strings or integers, of course)? Session? Cookie? Pass them around as parameter?
I'm a bit confused and would highly appreciate any suggestions.
Thanks!
Heinz Strunk wrote:
Hello,
I need some advice. I have a form that has data from 4 different tables and about 10 values to save and keep until the form is finally sent.
Where would you save the 10 values (all strings or integers, of course)? Session? Cookie? Pass them around as parameter?
If it's only one request cycle, there's no real need to save temp data. What are you trying to do?
I'm a bit confused and would highly appreciate any suggestions.
Thanks!
Best,
Is there any chance your form data needs to persist across sessions, (as in user leaves, comes back, resumes filling in unfinished form)?
If not, you could save your variables in a hash in session. Otherwise I would create a Form model and save it to the DB.
FWIW,
Hassan Schroeder wrote:
Is there any chance your form data needs to persist across sessions, (as in user leaves, comes back, resumes filling in unfinished form)?
If not, you could save your variables in a hash in session. Otherwise I would create a Form model and save it to the DB.
No, user doesn't leave. It just could end up in many request cycles. Didn't have the Session a very small amount of data it can save?
That depends on how you're handling sessions, but the more I think about it, I'd just go with the Form object and saving changes to the DB across requests.
FWIW,
If you are only talking about a few hundred bytes or less then you can certainly save it in the session. The alternative is to use fields in something like the User table, assuming there is one.
Colin
Well, most of it is actullay not any data that's going to be saved in the database. I need to know various numbers like "current number of users", "maximum number of users", "ids of the users" and stuff like that.
So I guess I should go for the session?
What do you mean by "current number of users"? Do you mean how many users are logged on? I got the impression in your original post that we were talking about data entered by the user. How do you know how many users are currently logged on? Remember that a session is on a user by user basis. If you want to remember data across users I think you will have to put it in the db.
Colin
Indeed, with the ActiveRecord store, you could count the number of sessions that were active in the last x minutes, but even that’s just an approximate value. With the CookieStore, you don’t have a way to determine the number of active users that easily (which certainly doesn’t mean you have to use the ActiveRecordStore again).
The only reliable way is maintaining a persistent connection to the server (using Juggernaut or Comet for example). When that connection is terminated, the user has logged off (it will even provide instant feedback when the window is closed, but the session is still persisting in the user’s browser).
Best regards
Peter De Berdt
Yes, in that case I would use the session, if you are really sure you can't just update the db as you go along. What is the issue with just updating the db as you go? The user will get really hacked off if he spends half an hour entering multiple forms only to lose it all when he loses connection for some reason.
Colin
Colin Law wrote:
No no no, you understood me wrong. It's just a form where you can add users to the object that is being created. It's a form, you click on add user you go to another page, add as many users as you want, go back to the main form. I need to know how many users have been added, which ones and if the maximum is reached.
Is it more clear now?
Yes, in that case I would use the session, if you are really sure you can't just update the db as you go along. What is the issue with just updating the db as you go? The user will get really hacked off if he spends half an hour entering multiple forms only to lose it all when he loses connection for some reason.
Colin
Well, good point but I'm not sure if I unerstood what you exactly mean by update db as you go. The group and it's users (which are being added in the sub form) have a m:n-relation so you'd create that relaion for each and every user being added and delete it again if something goes wrong or the user hits the cancel button? Looks like a lot of unnecessary db traffic to me. Or would you create another table only for the temp data?
I do not know enough about the application to say much more. I was suggesting updating the actual data rather than a temp table, but it was only a suggestion. I generally would suggest to do things the easiest way initially and only complicate it it if becomes necessary, though which is the easy way in your case I do not know. Certainly don't worry about the db traffic unless it becomes an issue.
Whichever route you go down make sure you have tests in place so you can refactor later and know it still works.
Colin
Colin Law wrote:
I do not know enough about the application to say much more. I was suggesting updating the actual data rather than a temp table, but it was only a suggestion. I generally would suggest to do things the easiest way initially and only complicate it it if becomes necessary, though which is the easy way in your case I do not know. Certainly don't worry about the db traffic unless it becomes an issue.
Whichever route you go down make sure you have tests in place so you can refactor later and know it still works.
Colin
Alright, thanks a lot to all of you! I'll keep both solutions in mind and see what's easier to use.
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks