Changes between Version 8 and Version 9 of CookBookMultiLevelMultiComponentDataModel

03/03/06 19:45:42 (10 years ago)
maney at two14 period net

sketch of what I've been doing to display nested sets so far


  • CookBookMultiLevelMultiComponentDataModel

    v8 v9  
    4242== See Also ==
     45== A New Beginning ==
     47I haven't a clue where this was intended to go, but I've recently started working with something that has such multilevel 1:many relations.  And I've seen questions about this even in the relatively little time I've spent on #django, so maybe even these sketchy notes will be useful.
     49=== Imagine a Perfectly Spherical Poll... ===
     51So a poll is one, with many related questions; likewise, each question has multiple related answers.  One of my first cuts, inspired no doubt by having just learned about Django's template faciltiies, hence wanting to use them, looked something like this:
     55<form action="/poll/submit/{{ poll.poll_id }}/{{ raw_args }}" method="post">
     57{% for q in poll.get_question_list %}
     58  <li>{{ q.prompt }}
     59  {% for a in q.get_answer_list %}
     60    <br /><input type="radio" name="question_{{ q.question_id }}" value="{{a.answer_id }}">{{ a.response }}
     61    {% endfor %}
     62  {% if arg.show_blank %}
     63    <br /><input type="radio" name="question_{{ q.question_id }}" value="-1"><input type="text" name="new_q_{{ q.question_id }}">
     64  {% endif %}
     65{% endfor %}
     67<input type="submit">
     71This requires really minimal setup in the view code - load the poll, set it up in the context dictionary that you'll pass to the rendering function, and there you go.
     72The virtue of simplicity, but also the limitations, as I discovered.
     74=== It was about that time that the Vogons came along ===
     76Well, maybe it was a few minutes later.  But I wanted to add some other features, such as an add-your-own-answer choice, but that needed to be conditional, and so forth.  And I ran into the simple reality that the template language gets really ugly really fast if you need to do too much logic in it.  Like, for example, adding the logic to set the radio button for a set of choices already made in the above display.  Or if the ordering of the nested data isn't what you wanted.  So I migrated some of the logic back into the view, and added a ''chosen_one'' attribute to the answers to make the template as simple as possible.  I '''think''' this is a generally good approach, even though I didn't get any opinions one way or the other when I asked #django for such.  So we'll see...
Back to Top