Hi Karen, Thanks a lot for such an elaborate answer. I took your advice and stepped back a few steps. I needed to plan it out better. What I was ultimately doing prior to this post was just trying to get it to save and then add the other features later, features that should really be required from the start, probably not the best idea in this case. I got it working now after reading what you've said here. I've properly built each model and have a working version with validation.
Thanks again On Apr 30, 2:43 pm, Karen Tracey <kmtra...@gmail.com> wrote: > On Thu, Apr 30, 2009 at 10:09 AM, tdelam <tde...@gmail.com> wrote: > > > Hi Karen, > > > Thanks for responding. > > > Okay so, here is the new forms code: > > > class TrueFalseForm(forms.Form): > > def __init__(self, q, *args, **kwargs): > > super(TrueFalseForm, self).__init__(*args, **kwargs) > > self.fields[q.title] = forms.ModelChoiceField( > > queryset=q.answer_set.all(), > > widget=forms.RadioSelect, > > empty_label=None, > > ) > > So you have a form, with a single field in it that is a ModelChoiceField. > The form is associated with a Question, the name of the form field is the > value of the title field of the Question, and the choices are the Answers > associated with that question. So when this form is POSTed what you will be > able to get from it is the instance of the selected Answer. > > (Note there is nothing about this form that restricts it to True/False > questions so its name is a bit confusing. Also I'm uneasy about the form > field name being the title field value from the question. I think you will > run into problem here if you ever put non-ASCII characters in your question > tittles.) > > > > > def save(self): > > choice = Answer( > > choice_answer = # selected answer, > > question = # Need Question instance > > ) > > choice.save() > > At the point where you want to save the submitted data, what you have in the > cleaned_data of the form is the selected Answer. Previously you were > passing q into the save(),so you could have retrieved the selected Answer > via: > > selected_answer = self.cleaned_data[q.title] > > Previously you were also creating in save() a different model, a > QuestionResponse, not an Answer. I am not sure why you have changed it to > creating a new Answer here? I don't believe you want to create a new Answer > when you save the form, as that would mean your answer_set for the Question > keeps growing and the next time you create a form for it you will have > multiple (identical) Answers listed. Perhaps you were moving towards adding > a field to Answer to track how many times it had been selected, so you could > do something like this in save? > > selected_answer.times_selected += 1 > selected_answer.save() > > That code is vulnerable to missing increments resulting from multiple > threads/processes in the web server simultaneously attempting to save an > increment for the same Answer, so if you were headed down this path and need > to ensure that all 'votes' are counted you'd have to worry about that. > > Alternatively you could go back to your original approach, where you created > a new instance of a different model (QuestionResponse) when saving. Only > what I think you want in a QuestionResponse is a ForeignKey to Answer, not a > CharField and a ForeignKey to Question as you had originally. Answer has > both those things already so I don't know why you would want to duplicate > them. Assuming your QuestionResponse has a field answer that is a > ForeignKey to Answer, then you could create a new QuestionResponse in save: > > QuestionResponse.objects.create(answer=self.cleaned_data[q.title]) > > But I think what you may want to do first is take a step back and rethink > your models. You've got some stuff in there that is half-implemented (the > question_type Question field) and it isn't clear to me that the models as > you've started laying them out are going to really support all the different > kinds of Questions you have in mind. > > Even for the simple select-one-from-a-list-of-choices your current Answer > model is cumbersome. If you've got multiple questions with the same Answers > (say for the True/False case), as you have it set up now you have to create > Answer True for Q1, Answer True for Q2, Answer False for Q1, Answer False > for Q2, etc. Getting rid of the ForeingKey to Question in Answer and > instead having a ManyToManyField of Answers in Question would make that > easier, but I'm not sure how well that will work for the other kinds of > questions you have in mind. > > You seem to have jumped into coding the full survey solution (show a bunch > of questions in a list and save all the answers on POST) before nailing down > some of the more basic issues: what all the question types will look like > and how they will be linked to answers and how the responses will be > recorded. Figure out the answers to those issues, and get things working > for a single question of each type you are interested in. Expanding that to > deal with a whole list of questions should then be straightforward. > > Karen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
