Hi, I''m a newbie even though I''ve play with rails for a few months now. I would like to save several activerecord objects (not in the database) accross several screens. What is the prefered rails way to do this? Should copy all of their data to @session or use the member variables and put them into hidden fields? I am trying to move from "whatever kludge works" to best practices, HJS -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On 11/25/06, H. joseph Solbrig <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Hi, > > I''m a newbie even though I''ve play with rails for a few months now. > > I would like to save several activerecord objects (not in the database) > accross several screens. > > What is the prefered rails way to do this? Should copy all of their data > to @session or use the member variables and put them into hidden fields? > > I am trying to move from "whatever kludge works" to best practices,Best practices IMO is to never store AR or any type of complex objects in your session,and use hidden fields sparingly as a last resort. Just use AR and validations. It takes a bit of time to learn enough AR to know how to structure things, but it''s worth it because that one investment in time will make your life much easier from there on out. For instance you can use update_attribute to save without validation, or use custom validations. You could for instance have an attribute in your model that determines what validations are performed based on it''s value, etc.. Chris --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
snacktime wrote:> On 11/25/06, H. joseph Solbrig <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: >> >> I am trying to move from "whatever kludge works" to best practices, > > > Best practices IMO is to never store AR or any type of complex objects > in your session,and use hidden fields sparingly as a last resort. > Just use AR and validations.I need to have a second screen for the user to validate the information before it is written to the database. What method other than sessions or fields (parameters) would be used? The record doesn''t exist in the database so I can''t store just ID. Screens: 1. Form for user to enter data 2. Page displaying data statically for validation with a bit of extra data to add. 3. Page saying data has been entered correctly -- How does 3 get the info in 1? Perhaps the rails model would insist I only use two screen but that seems rather rigid.> It takes a bit of time to learn enough > AR to know how to structure things, but it''s worth it because that one > investment in time will make your life much easier from there on out.The idea of object orientation is that you get to use objects without becoming an expert in them. If rails is designed so you need in-depth knowledge of the object to use it, rails is designed wrong. I''m not saying I don''t want to learn more about AR but the basic principle still stands. I know not to store a large amount of data in a session but I don''t see why I shouldn''t be able to store a complex item in it. Still, if there is a better way to store an AR object across multiple screens I''m eager to learn it. But I can''t see unpacking AR object into components and passing them as a better approach.> For instance you can use update_attribute to save without validation, > or use custom validations. You could for instance have an attribute > in your model that determines what validations are performed based on > it''s value, etc.. >Perhaps you were thinking I meant programmatic validation. I would agree that passing data with the session wouldn''t be needed but in the case> > Chris-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
H. joseph Solbrig wrote:> > snacktime wrote: >> On 11/25/06, H. joseph Solbrig <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: >>> >>> I am trying to move from "whatever kludge works" to best practices, >> >> >> Best practices IMO is to never store AR or any type of complex objects >> in your session,and use hidden fields sparingly as a last resort. >> Just use AR and validations. > > I need to have a second screen for the user to validate the information > before it is written to the database. What method other than sessions or > fields (parameters) would be used? The record doesn''t exist in the > database so I can''t store just ID. > > Screens: > 1. Form for user to enter data > 2. Page displaying data statically for validation with a bit of extra > data to add. > 3. Page saying data has been entered correctly > > -- How does 3 get the info in 1? > > Perhaps the rails model would insist I only use two screen but that > seems rather rigid.I have done such a thing with user sign up - User AR is stored in session, presented to user and then saved - probably not the best solution... Then I had to do a more complicated thing: I needed to edit a set of records. There is a screen with a list and a screen for editing each of them. Changes can be reverted, edited again and finally committed to the database (which requires additional processing). Edited records are given special, temporary ids aside from other data in the model (these were not stored in the database) and are stored in session. They are laid over the database models, so the edited versions are presented to the user instead of original ones from the database. The add, edit and revert operations got quite complex and I didn''t implement a "temporary" delete. I doubt this is best practice, I also doubt there is a simple way to do this in Rails, but I''d be happy to be shown wrong. -- Marcin Simonides P.S. There is the Seaside framework that looks promising in this aspect, but I haven''t tried it yet. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Use a (stub | unpublished | published) scheme. A stub has no (or very little) validation but allows a record to be created for the purpose of other records that may contain a foreign key to the stub. i.e. uploading images. An unpublished record has all the normal validation checks. i.e. a user cannot save an artical without body text, or a name. . . Setting the record to a published state will require perhaps some additional checks. i.e. artical is listed in appropriate categories, user has paid - whatever. Add a published boolean (or published_at datetime allowing null) column to the db and a new_stub() method to the model. The only purpose of the new_stub() method is to force a model into the db that would normally fail validation. Then the user can edit a model and it''s associated models in pretty much any order. Override the default published= method to do additional validation. I know this seems pretty inflexible but actually it works pretty well. I''ve used it on my current project and I''m glad I did. Hope it helps. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---