Mark, Here are some question I would raise in designing a domain model for an app like this:
- Can students and or instructors participate and or coordinate more than one course simultaneously? - Do you want to retain record of past participation? The reason why I pointed out the role pattern using :through is it allows you to append extra information to the association using a mediatory model class. If the answer to these two questions is no, it's completely not needed. FYI - The models are object classes in their own right. Everything in a Rails application is the a model if not acting upon or displaying results or searching (controller), or conveying model state (views). I tend to design applications from the model upward. I think in terms of model as the value of the application, controller as workflow, and the view agnostic of browser, API, or other. But I am coming from JEE. Peepcode, Meet Rails 3 Part 2 in specific walks the reader through building a project management system for the DeathStar. It would be a good screencast to watch and show you how to implement your app as the sample project is similar to what you are trying to do. If you don't want to buy, suggest you download and review the sample code for the project. Alternatively, if you can give us a little more information on your business logic, we can point you in the right direction to implement the model. Cheers, Rafael On Aug 6, 2011, at 4:43 PM, MC wrote: > Frederick, > > I would want to be able to see what students are being taught be what > instructor. And yes I would want to be able to know what the course > the student is taking. So from my current setup are you saying I > wouldn't get that? Or would I get that if I used a :through > association? > I'm sort of having a tough time wrapping my head around the > associations. I read the rails guide on associations but it's not > sticking yet. Is the whole point of associations being able to make > calls to the records because of active record's built in > capabilities? > > With regard to what you mentioned about CourseDate and CourseTime and > just making them additional columns. Could I still call that > information and post it to a calendar some how? > > My confusion over relationships starts making me think that I should > make everything an object class. Has anyone else felt this way? Is > there a guideline for when you make something it's own class as > opposed to just making it a column in a table? > > Mark > > On Aug 6, 2:42 am, Frederick Cheung <frederick.che...@gmail.com> > wrote: >> On Aug 6, 9:07 am, MC <amev...@gmail.com> wrote: >> >>> First crack at an app. I have a friend with a private school that I'm >>> trying to create a scheduling system for. >> >>> So I have Coordinators creating school courses. Once the course is >>> created the coordinator can assign multiple instructors, and then >>> assign students to the course and instructor. So is this right? >> >> Are you even going to need to have students that belong to multiple >> instructors? Are you going to want to know what course the student is >> taking ? From the associations you've given you don't seem to be >> storing that bit of information, the best you could work out is that >> given their instructor there are only certain courses they could be >> doing. >> >> >> >>> Then the other thing I want to do is set a date and time for each >>> course. So would I create this also: >> >>> class CourseDate >>> belongs_to :course >>> end >> >>> class CourseTime >>> belongs_to :coursedate >>> end >> >> Without a full understanding of your problem (perhaps you are managing >> repeating occurrences of courses etc.) this feels a little overkill to >> be honest. would date/time columns on your courses table not suffice? >> >> Fred >> >> >> >> >> >> >> >> >> >>> Thanks in advance, Mark > > -- > 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@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > -- 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@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
