http://www.pointy-stick.com/blog/2008/01/06/django-tip-complex-forms/
A shiny solution to the problem with code and the reasoning behind it.
Simon Willison is awesome.
On Jan 4, 1:03 pm, Wes Winham <[EMAIL PROTECTED]> wrote:
> Thanks Malcom. That reassured me greatly. I didn't think of the clever
> id meta-fields to keep the form from modification, but I ended up
> getting a shell implementation with each question being it's own
> question form, and the overallquizform just adds in as many question
> forms as there are questions in aquiz. I'll need to abstract out that
> functionality, just like you've suggested, but overall I think it will
> end up making sense in a month when I have to look at it again and I
> wonder who wrote this junk :)
>
> Thanks
> -Wes
>
> On Jan 3, 9:28 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>
> > On Thu, 2008-01-03 at 09:51 -0800, Wes Winham wrote:
> > > Hello,
>
> > > I've got a bit of a design issue I'm trying to wrap my head around in
> > > order to do things the Django Way.
>
> > > I'm attempting to creating a simple form that allows a user to take a
> > > multiple choice "quiz."Quizis a model and it has a many to many with
> > > Questions which has a m2m with AnswerOptions.
>
> > > I'm also not sure on which is the best way to get the questions and
> > > answers to the form and I'm not sure if I should be using one form, or
> > > a collection of forms.
>
> > Hmm .... deja vu. I've been working on an almost analogous problem this
> > morning. I haven't coded it all up yet, but here's my current design
> > thinking...
>
> > Each question is a form class. You can use the same form class each time
> > and part of its __init__ method will be to store the "question" string
> > (say in self.question). I will display 'N' of these on the page using
> > the "prefix" attribute to the form's __init__ method. So it will look
> > something like this:
>
> > class QuestionForm(forms.Form):
> > answers = forms.ChoiceField(widget=forms.RadioSelect)
>
> > def __init__(self, question, *args, **kwargs):
> > super(Question, self).__init__(*args, **kwargs)
> > self.question = question
> > self.fields['answers'].choices = ...
>
> > I also have some meta-information in the form, such as a security hash
> > to make sure the form isn't modified, so that uses another form class
> > (which currently just contains the security hash, but I might need other
> > stuff when I flesh things out).
>
> > Then my view will look like this:
>
> > def quiz_view(request, quiz_id):
> > quiz=Quiz.objects.get(pk=quiz_id)
> > if request.method == 'POST':
> > # TODO ...
> > else:
> > meta = MetaForm(quiz)
> > q_forms = []
> > for num, question in enumerate(quiz.questions.all()):
> > q_forms.append(QuestionForm(question, prefix=str(num)))
> > return render_to_response('quiz.html', {'meta': meta_form,
> > 'question_forms': q_forms})
>
> > and then, in the template:
>
> > <form ....>
> > {{ meta }}
> > {% for form in question_forms %}
> > <p>{{ form.question }}</p>
> > {{ form.as_p }}
> > {% endfor %}
> > <input type="submit" ...>
> > </form>
>
> > Obviously, a lot has been glossed over here (and there are no doubt some
> > bugs, as I haven't finalised the code in my case yet and I'm simplifying
> > a bunch of stuff). The point I want to make, though, is that I'm using
> > multiple form classes to render a *single* HTML form. I'm also shoving
> > things like the question text into the appropriate form so that I can
> > use that normally in the template (it's not a form field, so it wouldn't
> > normally be displayed).
>
> > In the final analysis, I'll end up pulling out the form creation stuff
> > into a separate function, since I need to do it in multiple places (at
> > least, in both the POST and GET paths), but that's just normal stuff.
>
> > Hopefully this gives you another idea to play with. I don't think any of
> > your options allowed for the possibility of multiple form classes, but
> > sometimes that can make things a lot easier.
>
> > Regards,
> > Malcolm
>
> > --
> > Save the whales. Collect the whole set.http://www.pointy-stick.com/blog/
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
