Thanks, Sharagoz. It is helpful. I guess you answered my big question,
which was whether or not STI is still relevant.
The design I''ve chosen is very similar to the one you describe. I
don''t have a need for the type of multiple choice that you describe,
what I needed was more like what you call Single only the student is
presented with options to choose from (i.e. "Choose the best answer
from this list"). For that, I''m just going to serialize the list
of
options into the Question table. I won''t need to have the complexity
of the chosen_answers you describe. Also, I''ve renamed my existing
classes to have one word as you suggest. I haven''t run into any
problems yet, but I haven''t really gotten too complicated either.
Thanks again.
On Apr 21, 8:18 am, Sharagoz
<shara...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> The questions and alternatives are going to be stored in the database,
> right?
> So basically somebody like a teacher can create a quiz that has many
> questions, which has many alternatives, and the students take a quiz
> where he responds to questions by picking alternatives or writing an
> essay.
>
> What makes this complicated is that there are different types of
> questions, (multiple choice, single choice, essay), which has
> consequences for the alternatives and the answers. I think it makes
> sense to use STI here so that there can be 3 sub-classes of question
> for each type. Without STI you will need a large amount of if-tests
> which makes messy code. STI wont make it hard to list questions and
> answers.
>
> I think the models need to be structured like this:
>
> Quiz has many questions
> Question has many alternatives
>
> When a student is answering the quiz, he is taking a test.
>
> Test belongs to student
> Test belongs to quiz
> Test has many answers
> Answer belongs to question (one answer per question)
> Answer has_many chosen_alternatives
> Chosen_alterntaive belongs to alternative (you might think that
> chosen_alternative is unnecessary, and that an answer can be hooked
> directly to an alternative, but this is going to create some issues
> for the multiple-choice questions).
> It is always a good idea to keep class names as single words where
> possible. Calling it "choice" instead of
"chosen_alternative" may be
> better.
>
> Then 3 sub-classes of question: Single, Multiple, Essay. This allows
> you to put logic in the subclasses and base behaviour on which type
> the question is. Examples of this would be; when the question is of
> type single, the student can only pick one alternative, when it is
> multiple, he can pick many. For the essay version no alternatives are
> created, hence no chosen_alternative will be created when the student
> answers. I would store this answer in a text field directly on the
> answer record. I also suspect that it would be a good idea to use STI
> on the answers, as some behaviour here will depend on which type the
> question is. Instead of having a bunch if-tests everywhere checking
> which type the question is and act accordingly, you can have 3 answer
> types in parallel with the 3 question types and split the logic that
> way.
>
> This response became a lot longer than I had planned. I hope some if
> it is usefull to you.
>
> On Apr 21, 4:46 am, DGerton
<dger...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
>
> > It''s often hard to keep up with changes in RoR, especially
when you''re
> > still learning. A lot information on the web is for older versions of
> > RoR. So I want to make sure this design using single-table inheritance
> > (STI) makes sense.
>
> > My design need is identical to this: I have a Quiz class, a Quiz
> > has_many Answers. Answers belong to a Student and a Question and
> > Answers can be types such as TrueFalse (a bool), MultipleChoice (a
> > string), Essay (a text), etc.
>
> > I want to query all the Answers for a particular Student and Quiz. Is
> > STI still the way to go for this? I am currently using Rails 2.3 but
> > have budgeted about a month to upgrade after Rails 3.0 is released.
>
> > TIA
>
> > --
> > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > For more options, visit this group
athttp://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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
> For more options, visit this group
athttp://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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.