I'm currently in my first app desgined using REST and after reading a few tutorials the basics are pretty clear, but I have a design problem that I bet is common, but I'm not sure of the best approach... Here are my classes/resources: class Player < ActiveRecord::Base ... has_many :trackers ... end class User < ActiveRecord::Base ... has_many :trackers ... end class Tracker < ActiveRecord::Base ... belongs_to :user belongs_to :player ... end I had no problem doing the basic generation of scaffolding and building out functionality for Player and User, but now that I'm building out the Trackers that allow a User to track a Player, I'm confused. I thought at first that maybe I'd set it up as a nested resource, but that's not making sense to me because a Tracker belongs to both a User and a Player. Also, from a user story design perspective, the basic thing here is that a user should be able to track a listed or displayed Player. So, I think one of the views will display lists of Players with each having a "Track" button or link next to them. I'd guess this will make use of a "new_tracker_path", but that would need to pass params for *both* the current User and the selected Player... right? (I tried it with just passing the Player ref and thought I could just deal with my @current_user variable in the controller, but something wasnt right) So, can anyone help with advice on best practices for this kind of design where a resource is joining two other resources?
on 2008-12-09 02:12
on 2008-12-09 18:01
It sounds to me like Users have Players is your nesting. Also, you seem to have a "has_many :through" join setup but have implemented a basic "has_many". Consider this change.... class Player < ActiveRecord::Base ... has_many :trackers has_many :users, :through => :trackers ... end class User < ActiveRecord::Base ... has_many :trackers has_many :players, :through => :trackers ... end class Tracker < ActiveRecord::Base ... belongs_to :user belongs_to :player ... end
on 2008-12-09 23:07
Thanks, Andy. It occurred to me this morning that it would useful to add the has_many/through to it. I'm still not clear though on the nested aspect of the design. I ~thought~ I needed to nest the *Trackers* under one or the other of Users or Players... this follows from my reading that resources that should be nested are those that cant really exist outside of another resource. In my case a Tracker doesnt make sense without the association with a Player first and without a User second... Players *can* exist without a User. Am I getting it right? Also, I seem to read that I can nest under *both* Users and Players. Things can get more complex, but it can be done. Is this true? If so, again, I'm curious what people say re: doing so... and back to my original post, would it better (aka simpler) to nest Trackers under Players and rely on a current_user variable being set to make that association in the TrackersController when a new Tracker is being created for a Player?
on 2008-12-09 23:40
I've always used HM :through for descriptive associations - usually I just want a created_at date so one could determine when a user joined a group (for example). I don't see how a "Tracker", which looks like a join, makes sense without both a User and a Player. This is correct understanding: "resources that should be nested are those that can't really exist outside of another resource" if a resource makes sense outside of the nesting then it shouldn't be nested. the traditional example is Article -> Comments - you could have Comments outside the context of an article - but they don't have much meaning