Author: jacob
Date: 2006-04-05 12:26:08 -0500 (Wed, 05 Apr 2006)
New Revision: 2616
Modified:
django/branches/magic-removal/docs/tutorial02.txt
django/branches/magic-removal/docs/tutorial04.txt
Log:
magic-removal: updated tutorials 2 and 4 to be magic-removal-complient (refs
#1464). Thanks to ChaosKCW and jbowtie.
Modified: django/branches/magic-removal/docs/tutorial02.txt
===================================================================
--- django/branches/magic-removal/docs/tutorial02.txt 2006-04-05 17:14:09 UTC
(rev 2615)
+++ django/branches/magic-removal/docs/tutorial02.txt 2006-04-05 17:26:08 UTC
(rev 2616)
@@ -83,25 +83,25 @@
Just one thing to do: We need to specify in the ``Poll`` model that ``Poll``
objects have an admin interface. Edit the ``myproject/polls/models/polls.py``
-file and make the following change to add an inner ``Meta`` class with an
-``admin`` attribute::
+file and make the following change to add an inner ``Admin`` class::
- class Poll(meta.Model):
+ class Poll(models.Model):
# ...
- class Meta:
- admin = meta.Admin()
+ class Admin:
+ pass
-The ``class Meta`` contains all `non-field metadata`_ about this model.
+The ``class Admin`` will contain all the settings that control how this model
+appears in the Django admin. All the settings are optional, however, so
+creating an empty class means "give this object an admin interface using
+all the default options."
Now reload the Django admin page to see your changes. Note that you don't have
to restart the development server -- it auto-reloads code.
-.. _non-field metadata:
http://www.djangoproject.com/documentation/model_api/#meta-options
-
Explore the free admin functionality
====================================
-Now that ``Poll`` has the ``admin`` attribute, Django knows that it should be
+Now that ``Poll`` has the inner ``Admin`` class, Django knows that it should be
displayed on the admin index page:
.. image:: http://media.djangoproject.com/img/doc/tutorial/admin03t.png
@@ -125,7 +125,7 @@
Things to note here:
* The form is automatically generated from the Poll model.
-* The different model field types (``meta.DateTimeField``, ``meta.CharField``)
+* The different model field types (``models.DateTimeField``,
``models.CharField``)
correspond to the appropriate HTML input widget. Each type of field knows
how to display itself in the Django admin.
* Each ``DateTimeField`` gets free JavaScript shortcuts. Dates get a "Today"
@@ -157,13 +157,12 @@
Take a few minutes to marvel at all the code you didn't have to write.
Let's customize this a bit. We can reorder the fields by explicitly adding a
-``fields`` parameter to ``meta.Admin``::
+``fields`` parameter to ``Admin``::
- admin = meta.Admin(
+ class Admin:
fields = (
(None, {'fields': ('pub_date', 'question')}),
- ),
- )
+ )
That made the "Publication date" show up first instead of second:
@@ -176,12 +175,11 @@
And speaking of forms with dozens of fields, you might want to split the form
up into fieldsets::
- admin = meta.Admin(
+ class Admin:
fields = (
(None, {'fields': ('question',)}),
('Date information', {'fields': ('pub_date',)}),
- ),
- )
+ )
The first element of each tuple in ``fields`` is the title of the fieldset.
Here's what our form looks like now:
@@ -195,12 +193,11 @@
This is useful when you have a long form that contains a number of fields that
aren't commonly used::
- admin = meta.Admin(
+ class Admin:
fields = (
(None, {'fields': ('question',)}),
('Date information', {'fields': ('pub_date',), 'classes':
'collapse'}),
- ),
- )
+ )
.. image:: http://media.djangoproject.com/img/doc/tutorial/admin09.png
:alt: Fieldset is initially collapsed
@@ -214,13 +211,13 @@
Yet.
There are two ways to solve this problem. The first is to give the ``Choice``
-model its own ``admin`` attribute, just as we did with ``Poll``. Here's what
+model its own inner ``Admin`` class, just as we did with ``Poll``. Here's what
that would look like::
- class Choice(meta.Model):
+ class Choice(models.Model):
# ...
- class Meta:
- admin = meta.Admin()
+ class Admin:
+ pass
Now "Choices" is an available option in the Django admin. The "Add choice" form
looks like this:
@@ -242,18 +239,18 @@
It'd be better if you could add a bunch of Choices directly when you create the
Poll object. Let's make that happen.
-Remove the ``admin`` for the Choice model. Then, edit the ``ForeignKey(Poll)``
+Remove the ``Admin`` for the Choice model. Then, edit the ``ForeignKey(Poll)``
field like so::
- poll = meta.ForeignKey(Poll, edit_inline=meta.STACKED, num_in_admin=3)
+ poll = models.ForeignKey(Poll, edit_inline=models.STACKED, num_in_admin=3)
This tells Django: "Choice objects are edited on the Poll admin page. By
default, provide enough fields for 3 Choices."
Then change the other fields in ``Choice`` to give them ``core=True``::
- choice = meta.CharField(maxlength=200, core=True)
- votes = meta.IntegerField(core=True)
+ choice = models.CharField(maxlength=200, core=True)
+ votes = models.IntegerField(core=True)
This tells Django: "When you edit a Choice on the Poll admin page, the 'choice'
and 'votes' fields are required. The presence of at least one of them signifies
@@ -277,9 +274,9 @@
fields for entering related Choice objects. For that reason, Django offers an
alternate way of displaying inline related objects::
- poll = meta.ForeignKey(Poll, edit_inline=meta.TABULAR, num_in_admin=3)
+ poll = models.ForeignKey(Poll, edit_inline=models.TABULAR, num_in_admin=3)
-With that ``edit_inline=meta.TABULAR`` (instead of ``meta.STACKED``), the
+With that ``edit_inline=models.TABULAR`` (instead of ``models.STACKED``), the
related objects are displayed in a more compact, table-based format:
.. image:: http://media.djangoproject.com/img/doc/tutorial/admin12.png
@@ -302,18 +299,16 @@
``list_display`` option, which is a tuple of field names to display, as
columns,
on the change list page for the object::
- class Poll(meta.Model):
+ class Poll(models.Model):
# ...
- class Meta:
- admin = meta.Admin(
- # ...
- list_display = ('question', 'pub_date'),
- )
+ class Admin:
+ # ...
+ list_display = ('question', 'pub_date')
Just for good measure, let's also include the ``was_published_today`` custom
method from Tutorial 1::
- list_display = ('question', 'pub_date', 'was_published_today'),
+ list_display = ('question', 'pub_date', 'was_published_today')
Now the poll change list page looks like this:
@@ -336,7 +331,7 @@
Let's add another improvement to the Poll change list page: Filters. Add the
following line to ``Poll.admin``::
- list_filter = ['pub_date'],
+ list_filter = ['pub_date']
That adds a "Filter" sidebar that lets people filter the change list by the
``pub_date`` field:
@@ -352,7 +347,7 @@
This is shaping up well. Let's add some search capability::
- search_fields = ['question'],
+ search_fields = ['question']
That adds a search box at the top of the change list. When somebody enters
search terms, Django will search the ``question`` field. You can use as many
@@ -362,7 +357,7 @@
Finally, because Poll objects have dates, it'd be convenient to be able to
drill down by date. Add this line::
- date_hierarchy = 'pub_date',
+ date_hierarchy = 'pub_date'
That adds hierarchical navigation, by date, to the top of the change list page.
At top level, it displays all available years. Then it drills down to months
Modified: django/branches/magic-removal/docs/tutorial04.txt
===================================================================
--- django/branches/magic-removal/docs/tutorial04.txt 2006-04-05 17:14:09 UTC
(rev 2615)
+++ django/branches/magic-removal/docs/tutorial04.txt 2006-04-05 17:26:08 UTC
(rev 2616)
@@ -49,13 +49,13 @@
So let's create a ``vote()`` function in ``myproject/polls/views.py``::
from django.shortcuts import get_object_or_404, render_to_response
- from django.models.polls import choices, polls
from django.http import HttpResponseRedirect
+ from myproject.polls.models import Choice, Poll
def vote(request, poll_id):
- p = get_object_or_404(polls, pk=poll_id)
+ p = get_object_or_404(Poll, pk=poll_id)
try:
- selected_choice = p.get_choice(pk=request.POST['choice'])
+ selected_choice = p.choice_set.filter(pk=request.POST['choice'])
except (KeyError, choices.ChoiceDoesNotExist):
# Redisplay the poll voting form.
return render_to_response('polls/detail', {
@@ -102,7 +102,7 @@
page for the poll. Let's write that view::
def results(request, poll_id):
- p = get_object_or_404(polls, pk=poll_id)
+ p = get_object_or_404(Poll, pk=poll_id)
return render_to_response('polls/results', {'poll': p})
This is almost exactly the same as the ``detail()`` view from `Tutorial 3`_.
@@ -168,10 +168,10 @@
Change it like so::
from django.conf.urls.defaults import *
-
+ from myproject.polls.models import Poll
+
info_dict = {
- 'app_label': 'polls',
- 'module_name': 'polls',
+ 'queryset': Poll.objects.all(),
}
urlpatterns = patterns('',
@@ -185,10 +185,8 @@
Respectively, those two views abstract the concepts of "display a list of
objects" and "display a detail page for a particular type of object."
- * Each generic view needs to know which ``app_label`` and ``module_name``
- it's acting on. Thus, we've defined ``info_dict``, a dictionary that's
- passed to each of the generic views via the third parameter to the URL
- tuples.
+ * Each generic view needs to know which model its acting on. This
+ is done using a QuerySet.
* The ``object_detail`` generic view expects that the ID value captured
from the URL is called ``"object_id"``, so we've changed ``poll_id`` to
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@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-updates
-~----------~----~----~----~------~----~------~--~---
