URL configuration tips:
Method 1:
1 from django.conf.urls.defaults import * 2 from mysite.views import current_datetime, hours_ahead, hours_behind, now_in_chicago, now_in_london 3 4 urlpatterns = patterns('', 5 ('time/', current_datetime), 6 ('time/plus/(\d{1,2})/', hours_ahead), 7 ('time/minus/(\d{1,2})/', hours_behind), 8 ('time/in_chicago/', now_in_chicago), 9 ('time/in_london/', now_in_london), 10 )
Method 2:
1 from django.conf.urls.defaults import * 2 from mysite import views 3 4 urlpatterns = patterns('', 5 ('time/', views.current_datetime), 6 ('time/plus/(\d{1,2})/', views.hours_ahead), 7 ('time/minus/(\d{1,2})/', views.hours_behind), 8 ('time/in_chicago/', views.now_in_chicago), 9 ('time/in_london/', views.now_in_london), 10 )
Method 3:
from django.conf.urls.defaults import * urlpatterns = patterns('website.views', ('time/', 'website.views.current_datetime'), ('time/plus/(\d{1,2})/', 'website.views.hours_ahead'), ('time/minus/(\d{1,2})/', 'website.views.hours_behind'), ('time/in_chicago/', 'website.views.now_in_chicago'), ('time/in_london/', 'website.views.now_in_london'), )
The result of the url configuration of method 1 is the same as that of method 2 and method 3. The disadvantage of the above configuration is that if multiple functions are imported, they must be imported all the time in front of the code, which is cumbersome,
The following is the string technology. As long as you add a parameter to the url configuration, you don't need to import it in the front. Also, note that the quotation marks around the parameter here. django will automatically process the string here
Use multiple view prefixes:
In practice, if you use string technology, especially if you don't have a common prefix in your URLconf, you may end up mixing views. However, you can still use the simple way of view prefixes to reduce duplication. Just add more than one pattern () object, like this: (the code in the following two parts is based on Django1.1)
old:
1 from django.conf.urls.defaults import * 2 3 urlpatterns = patterns('', 4 (r'^/?$', 'mysite.views.archive_index'), 5 (r'^(\d{4})/([a-z]{3})/$', 'mysite.views.archive_month'), 6 (r'^tag/(\w+)/$', 'weblog.views.tag'), 7 )
new:
1 from django.conf.urls.defaults import * 2 3 urlpatterns = patterns('mysite.views', 4 (r'^/?$', 'archive_index'), 5 (r'^(\d{4})/([a-z]{3})/$', 'archive_month'), 6 ) 7 8 urlpatterns += patterns('weblog.views', 9 (r'^tag/(\w+)/$', 'tag'), 10 )
The whole framework focuses on the existence of a module level variable called urlpatterns. This variable can be built dynamically, as we did in this example.
Create a common view:
1 # urls.py 2 3 from django.conf.urls.defaults import * 4 from mysite import views 5 6 urlpatterns = patterns('', 7 (r'^events/$', views.event_list), 8 (r'^blog/entries/$', views.entry_list), 9 ) 10 11 # views.py 12 13 from django.shortcuts import render_to_response 14 from mysite.models import Event, BlogEntry 15 16 def event_list(request): 17 obj_list = Event.objects.all() 18 return render_to_response('mysite/event_list.html', {'event_list': obj_list}) 19 20 def entry_list(request): 21 obj_list = BlogEntry.objects.all() 22 return render_to_response('mysite/blogentry_list.html', {'entry_list': obj_list})
The two views do essentially the same thing: show a series of objects. Let's abstract the types of objects they display:
1 # urls.py 2 3 from django.conf.urls.defaults import * 4 from mysite import models, views 5 6 urlpatterns = patterns('', 7 (r'^events/$', views.object_list, {'model': models.Event}), 8 (r'^blog/entries/$', views.object_list, {'model': models.BlogEntry}), 9 ) 10 11 # views.py 12 13 from django.shortcuts import render_to_response 14 15 def object_list(request, model): 16 obj_list = model.objects.all() 17 template_name = 'mysite/%s_list.html' % model.__name__.lower() 18 return render_to_response(template_name, {'object_list': obj_list})
-
We pass the model class directly through the model parameter. The dictionary for the extra URLconf parameter is that you can pass any type of object, not just strings.
-
This line: model.objects.all() is an example of duck typing: if a bird walks like a duck and calls like a duck, then we can treat it as a duck. It should be noted that the code does not know what the type of the model object is; it only needs to ask that the model has an objects attribute, and this attribute has an all() method
-
We use model. Name. Lower () to determine the name of the template. Each Python class has a \\\\\\\\\. This feature is useful when we don't know the object type until runtime. For example, the name of the BlogEntry class is the string 'BlogEntry'.
-
This example is slightly different from the previous one. We passed a common variable name to the template. Of course, we can easily change the variable name to blog try list or event list, but we intend to leave this as an exercise for the readers.