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! -- Posted via http://www.ruby-forum.com/.
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, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
Marnen Laibow-Koser wrote:> > If it''s only one request cycle, there''s no real need to save temp data. > What are you trying to do? >That''s exactly my problem, otherwise I would be using variables. It''s many request cycles going back and forth that''s why I need a proper way to save some data. I''m doing it by passing parameters but it''s confusing and I don''t like parameter when handling so many variables. -- Posted via http://www.ruby-forum.com/.
On Fri, Nov 6, 2009 at 3:23 PM, Heinz Strunk <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> That''s exactly my problem, otherwise I would be using variables. It''s > many request cycles going back and forth that''s why I need a proper way > to save some data. I''m doing it by passing parameters but it''s confusing > and I don''t like parameter when handling so many variables.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 ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan
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? -- Posted via http://www.ruby-forum.com/.
On Sat, Nov 7, 2009 at 12:49 AM, Heinz Strunk <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> 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, -- Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan
2009/11/6 Heinz Strunk <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>:> > Marnen Laibow-Koser wrote: >> >> If it''s only one request cycle, there''s no real need to save temp data. >> What are you trying to do? >> > That''s exactly my problem, otherwise I would be using variables. It''s > many request cycles going back and forth that''s why I need a proper way > to save some data. I''m doing it by passing parameters but it''s confusing > and I don''t like parameter when handling so many variables.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? -- Posted via http://www.ruby-forum.com/.
2009/11/9 Heinz Strunk <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>:> > 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
On 09 Nov 2009, at 16:35, Colin Law wrote:>> 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.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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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? -- Posted via http://www.ruby-forum.com/.
2009/11/9 Heinz Strunk <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>:> > 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
Colin Law wrote:> 2009/11/9 Heinz Strunk <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>: >> >> 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. > > ColinWell, 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? -- Posted via http://www.ruby-forum.com/.
2009/11/9 Heinz Strunk <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>:> > Colin Law wrote: >> 2009/11/9 Heinz Strunk <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>: >>> >>> 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. > > ColinAlright, thanks a lot to all of you! I''ll keep both solutions in mind and see what''s easier to use. -- Posted via http://www.ruby-forum.com/.