Üstün Özgür

Filed undertech

Follow me on Twitter! http://twitter.com/ustunozgur

Email: ustunozgur+blog 'at' gmail.com

Follow me on Twitter!

Twitter

Üstün Özgür's profile »

Django for Dummies: First Notes About Django

These are some of my notes about Django after going through the official tutorial.

To build a Django site, one first creates a project using django-admin command.

A project is made up of several apps, some of which are from Django itself (like admin, authentication) and some others which you might write.

Next, we create a new app inside the project. Afterwards, using the setting.py of the project, we indicate how the database is created, and which apps are used in our project.

After that, doing manage.py syncdb creates the necessary database tables. (This command only creates tables for new apps, so tables are not recreated if they exist.)

Inside the settings.py, the URL_ROOT parameter is given as a urls.py file location, which is responsible for routing the incoming requests to matching views. The matching is done via regexes.

The other files in the project root are:

__init__.py : This indicates that this is a module
manage.py: This file is responsible for a bunch of things: runserver, syncdb etc.

Once you create an app inside the project, the new app will have the following files:

__init__.py : Empty, indicates that it is a module
models.py : Models go in here. Models have a unicode method to give their descriptions.

All models originate from models.Model, so import from django.db models class The model class can reach to all its instances. So, for example, if you have a Poll model, the Poll object can access all the Poll instances (via Poll.objects.all() for example)
views.py : The functions in this file indicate how requests are shown to the user. The mapping is done in urls.py at the project level or if the urls.py includes the urls.py at the app level, the mapping is done by the urls.py of the application itself. The request shown to do user are generated like this: First, a dictionary is formed which consists of the required information for the answer. This is called the context. Then, a template is generated as an html file which includes a Django template (The location for the template files is indicated within the settings.py). Finally, the context is rendered with the template.
admin.py : This file is not created automatically, create this if you want admin functionality for the models. You need to activate the admin app from settings.py of the project, and import the admin class from django.contrib. You create some classes which show how the models should be displayed on the admin page. You create fieldsets, list_filters, etc here, and finally register via the admin class. For example, admin.site.register(Poll, PollAdmin) command registers the newly created PollAdmin class with the Poll object in the database.

Some Tips/Shortcuts

When getting an object from the database to display, one can use get_object_or_404 so that one can give 404 if there is no match.
To render a context with a template, use the render_to_response shortcut. render_to_response(template_name, context_dictionary)
Default template html’s are used if no matching template is found.
For the contrib apps, see http://docs.djangoproject.com/en/1.1/ref/contrib/

Questions

How is the template directories organized? How does it really find the required files?
For forms, look at: http://docs.djangoproject.com/en/1.1/ref/forms/
What are generic views? http://docs.djangoproject.com/en/1.1/ref/forms/
How do we use it with GAE?
Q: Other than the startproject command, the manage.py and django-admin.py seem identical.

A: From the docs: manage.py is a thin wrapper around django-admin.py that takes care of two things for you before delegating to django-admin.py:

It puts your project’s package on sys.path.
It sets the DJANGO_SETTINGS_MODULE environment variable so that it points to your project’s settings.py file.

So, it seems that we should almost always use manage.py.