A collection of notes and links that'll help you with this week's assignment.
The assignment is to rough out your project's core models, and have a basic usable admin interface to those models. You don't need to do ALL the models your site will need, but the two or three core ones (I've sat down with most of you to identify what those will be; if you aren't sure get in touch with me.) The models don't need much, just their fields, a reasonable __unicode__ method so they show up nicely in the admin, and perhaps a default ordering.
You also don't need to do a fully customized admin interface. The
one customization I would like you to make is that if you have models
that make most sense edited as "part" of another model (like editing
Choices as part of a Poll) I would like to see you do them as
a TabularInline, just like in the tutorial. Also define
list_display and list_editable if they make sense for your models.
Basically, we want to get your project to a similar state as the tutorial project was in after part 2.
My "grading check" for this assignment next Wednesday will be to clone your project using Mercurial (so everything needs to be committed), syncdb (and migrate if needed), run the runserver, and then be able to log in to the admin and create instances of all your models.
We're ramping up the challenge factor this week compared to past weeks. I think it's time for that (if we want to actually have working projects by the end of the semester), and I think you all can handle it.
Getting this assignment done will require going out and looking for the information you need and doing some reading: the Django docs are very helpful if you take the time to read carefully. For this assignment, you'll probably find most helpful the model docs, the field type reference, and the admin docs; as well as maybe going back to look at part 1 and part 2 of the tutorial.
...from class is available
at http://dj.goshen.edu/~carljm/feedback/. You
can browse it via the web (though not real conveniently as your
browser will want to download every .py file), or run hg clone
http://dj.goshen.edu/~carljm/feedback/ to get yourself a local
copy.
Most (all?) of your projects will have users. You would need to
define a User model to store information about those users, except
that Django has one already that you can just use. It lives
at django.contrib.auth.models.User. You can
see documentation
on it
and the
actual code for it - pretty similar to what we're doing, although
they pass some "translatable names" as the first argument to each
field, and some help_text attributes to make the admin interface
friendlier.
You'll probably have extra information about your users that doesn't fit into the fields on the generic User model. The solution to that is to define your own Profile or UserProfile model with a OneToOneField to User. Something like this:
from django.db import models
from django.contrib.admin.models import User
class UserProfile(models.Model):
user = models.OneToOneField(User)
favorite_color = models.CharField(max_length=100)
# ...
Many of your projects include voting functionality. If what you want is simple up/down voting, rather than writing that yourself, I recommend using the generic django-voting app. We can talk about the details of that when you get to that user story; for now just know that you don't need to add models or attributes for up/down voting.
If you want more of a rating scale (like 1-5 or 1-10), django-voting doesn't handle that, so you'd want to write it yourself.
As you're working on your models, chances are you'll need to change them. If you've already synced them once, you'll need to do one of two things: delete your database and re-sync, or else use South migrations.
Since you won't have much data at this point, deleting and
re-syncing is a reasonable option; just delete your SQLite database
file and re-run python manage.py syncdb every time your
models change. You'll have to re-create any test data you had.
If you do feel like learning to use South and migrations (and you'll need to eventually), here's what you'll need to do:
south==0.6 to
your requirements.txt file.pip install -r
requirements.txt to get it installed.INSTALLED_APPS
in settings.pypython manage.py startmigration --initial
appname to create your initial model-creating migration (note
that if you've already run syncdb, you need to create your initial
migration with the same models.py that you ran syncdb with;
i.e. before you make any changes to it).python manage.py migrate appname --fake to
"fake" that first migration (since the models were already created
by syncdb (replace appname with the name of the app you're
syncing).python
manage.py startmigration --auto appname migration_name, where
migration_name is some descriptive name like
"added_order_field_to_question".python manage.py migrate to migrate your
database.From here on out, the last two steps are all you'll need.
This is a required dependency if you want to use an ImageField for storing images in your models. It's now installed on dj.goshen.edu, so you shouldn't have trouble there.
(Normally I prefer installing dependencies only inside a virtualenv. The reason I don't mind installing PIL globally is that it isn't under active development, so there's only one version of it you're ever likely to want: the most recent, 1.1.6. This means you won't likely run into issues where you have a working site using an older version, but want to use a newer version on a new project. Also, PIL has to be compiled from C code, so it can be more difficult to repeatedly install inside each virtualenv compared to your typical Python package.)
If you're working on your own Mac, you'll need to install PIL yourself. One option is to install it globally using the dmg package linked at this site. I know this works for OSX 10.5 (Leopard), I'm not sure it does for 10.6 (Snow Leopard). If you're on Snow Leopard, you might try the instructions here (you'll have to have Xcode installed). There is also a suggestion here of using a different URL for PIL that might help.