Have you ever searched the App Store for Django apps? Don’t bother, as of this post there is only one that will come up: Django Documentation. Since it was only 99 cents, I bought it a few weeks back and I wouldn’t recommend that you do the same. It is simply the online Django documentation “formatted” for the iPhone and iPod Touch.
Guess what? If you use your iPhone to browse to the Django documentation page with your free Mobile Safari app you’ll also get the Django documentation “formatted” for you iPhone or iPod Touch, and you’ll also get the ability to bookmark pages, easily go forward and back in your page history and zoom in and out on text.
For the past couple weeks I’ve had the paid app sitting side-by-side with a Safari bookmark on my iPhone:

Paid app on far right, standard bookmark to the left of it, new bookmark to the left of that
My only problem with adding the Safari bookmark to the home screen? The ugly default icon it creates. For some reason, it *really* bothers me. Sure, it’s an accurate representation of the page it bookmarks, but it doesn’t make for a very good icon.
What I have done — and you can see it immediately to the left of the Safari bookmark — is create a front page to the standard Django docs so when you bookmark it, it makes a presentable icon suitable for the iPhone. The downside is that when you click on this icon, you go to that front page and then have to click the huge “dj” button to get to the docs. For me, however, this is worth it.
If you care about the appearance of your iPhone icons and want to have the Django docs on your own phone, do the following:
- open Mobile Safari
- browse to http://be73.com
- click the “+” icon on the bottom of the screen
- click the “Add to Home Screen” button
- click “Add”
Done. May my fellow OCD suffers rest easily tonight.
UPDATE: In the comments Phillip Bosch points out that I can use a more standard <link rel=”apple-touch-icon” href=”django-icon.png”> to produce an even better icon. Using this, I have iframed the django docs, so clicking on the icon goes directly there while still producing a nice iPhone/touch-friendly icon. Thanks Phillip!
Customizing Django Comments: Remove Unwanted Fields
I recently added comments to a new Django site that I’m working on (Wantbox.com = craigslist[::-1] + stack overflow). Comments pose an interesting problem as they can have a number of “parents”. In my case, the parent might be a user’s “Want” a respondent’s “Have” or possibly another “Comment.”
In the process of researching the best way to architect Wantbox’s comments app, I read about “polymorphic associations“, “exclusive arcs” and Django’s ContentType framework. Using this knowledge, I contemplated recreating the comment wheel, since I wanted my comment form to just be a simple “Stack Overflow-type” comment-only field and not the larger “WordPress-type” name/email/website/comment.
As I explored Django’s comments framework deeper, I realized that recreating another comment app was a waste of my time and my end product would be far less feature rich than Django’s bundled commenting system. Below are my modifications which allowed me to quickly and easily twist Django comments into what I needed.
My Django Comment Modifications:
To customize the default comment form and comment list display, I created a “comments” directory in my root “templates” directory and simply overrode the two default comment templates “form.html” and “list.html”.
My custom “/templates/comments/form.html”:
{% load comments i18n %} {% if user.is_authenticated %} <form action="{% comment_form_target %}" method="post"> {% csrf_token %} {% if next %}<input name="next" type="hidden" value="{{ next }}" />{% endif %} {% for field in form %} {% if field.is_hidden %} {{ field }} {% else %} {% if field.name != "name" and field.name != "email" and field.name != "url" %} {% if field.errors %}{{ field.errors }}{% endif %} {{ field }} {% endif %} {% endif %} {% endfor %} <input class="submit-post" name="post" type="submit" value="{% trans " /> </form> {% else %} I'm sorry, but you must be <a href="javascript:alert('send to login page')">logged in</a> to submit comments. {% endif %}Which is only slightly different from the default Django comments form.html, primarily suppressing the display of the not-wanted and not-required “name”, “email” and “url” input fields.
My custom “/templates/comments/list.html”:
<div class="comment_start"></div> {% for comment in comment_list %} <div class="comment"> {{ comment.comment }} (from <a href="javascript:alert('show user profile/stats')">{{ comment.user }}</a> - {{ comment.submit_date|timesince }} ago) </div> {% endfor %}In the template where I want to invoke the comments form, I first call
{% load comments %}and then{% render_comment_form for [object] %}to show the form, or{% render_comment_list for [object] %}to generate a list of the comments on the object (replace [object] with your appropriate object name). So easy.This solution is working great for me, and still giving me all the other “free” stuff that comes with django comments (moderation, flagging, feeds, polymorphic associations, helpful template tags, etc…). The moral of this story: don’t recreate the wheel when an hour or two of research can give it to you for free.
NOTE: This blog post is based on my Stack Overflow answer to Ignacio’s question “How to extend the comments framework (django) by removing unnecesary fields?“