* Is the user logged in? Are you using devise gem? If so (recommend), you have access to the current user using the current_user controller variable (provided by devise). Using devise with a proper authentication system is the way to go. There are alternatives to devise too.
More responses inline: On Oct 20, 2014, at 1:34 PM, Brian Sammon <rubyonrails-l...@brisammon.fastmail.fm> wrote: > What's the current best practice for getting the userID from the sesson, > and having it be part of every newly created/modified record? > > I have an app with a Club model and a People model, and a "membership" > join table. > > class Club < ActiveRecord::Base > has_many(:memberships) > has_many(:members, class_name: 'People', through: :memberships) > end > > I want all the tables, including the membership join table, to have a > "creator" field that gets populated every time the record is created > updated. Is created or updated? That sounds like updated_by_user_id (or last_updated_by). There are gems for that, and you should use them. I think maybe even devise may have that built-in. In which case you may not need to worry about that stuff in your controller. > I'd especially like to do stuff in my controller like the > following: Too much domain logic in the Controller is a common antipattern. Avoid too much domain logic in your controllers. They should be light and pass off all domain logic to context objects or model objects (or some other domain-layer). > c = Club.find(name: => 'The Rubyists') > c.members << People.find(name: ['Joe','Ann']) > Generally you always find things by IDs (unless you're searching for something based on a user query). Not sure why you would want to do a find by a name. I could see use case for this, but I'd be concerned with access control here. The cancan or cancancan gem help with access control. > and have it populate the membership table correctly. > > Google has found me various articles/posts related to various versions > of rails, some of which say something like "if you're doing this, > you're Doing It Wrong", and many of which suggest putting information > in a thread-local variable. I've seen this pattern before (back in the Rails 1 and Rails 2 days), it is generally frowned upon at this point. Simply passing the current_user down to the model from the controller is perfectly fine in my opinion. Consider having a class (plain-old-ruby-object) that is responsible for adding members to clubs. So in your controller, you'd write some code like this (this example is ridiculous, but is for illustrating a point) club = Club.find(params[:id]) joe_user = User.JOE members = [current_user, joe_user] creator = ClubMemberCreator.new(club, members) creator.create! The ClubMemberCreator object may do a bunch of things for you (manipulate the stats about the club, spawn some worker jobs to perform operations on the memberships, send some emails to the new members welcoming them!). By putting it in its own object, you are abstracting the quickly changing logic from the slow- change logic. (see Coplien Lean Architecture), and you also moving domain logic out of the controller so it can be re-used by another controller doing the same thing. This is a good pattern and makes a lot of sense in a large app. > > I worry that some of these suggestions I've find make assumptions about > how Rails works under the hood that may not hold true for every > deployment method. > That's a good thing to worry about. Using the best tool for the job, your best judgement, and knowledge about what has worked in the past to guide you in making the least-objectionable choice. ---- Jason Fleetwood-Boldt t...@datatravels.com http://www.jasonfleetwoodboldt.com/writing All material (c) Jason Fleetwood-Boldt 2014. Public conversations may be turned into blog posts (original poster information will be made anonymous). Email ja...@datatravels.com with questions/concerns about this. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/D56C0008-FCCB-44FD-9557-2B33381D7F52%40datatravels.com. For more options, visit https://groups.google.com/d/optout.
