Skip to main content

Home/ Groups/ interesting_sites
pagetribe .

senduit | Share easily. - 1 views

shared by pagetribe . on 11 Nov 09 - Cached
pagetribe .

Chapter 11: Generic Views - 0 views

  • from django.conf.urls.defaults import * from django.views.generic import list_detail from mysite.books.models import Publisher publisher_info = { 'queryset': Publisher.objects.all(), 'template_name': 'publisher_list_page.html', } urlpatterns = patterns('', (r'^publishers/$', list_detail.object_list, publisher_info) )
  • That’s really all there is to it. All the cool features of generic views come from changing the “info” dictionary passed to the generic view.
  • You might have noticed that sample publisher list template stores all the books in a variable named object_list.
  • ...10 more annotations...
  • it isn’t all that “friendly” to template authors: they have to “just know” that they’re dealing with books here.
  • better name
  • publisher_list;
  • 'template_object_name': 'publisher',
  • If you want to present a list of books by a particular publisher, you can use the same technique:
  • Another common need is to filter the objects given in a list page by some key in the URL. Earlier we hard-coded the publisher’s name in the URLconf, but what if we wanted to write a view that displayed all the books by some arbitrary publisher?
  • “wrap” the object_list generic view
  • # Look up the publisher (and raise a 404 if it can't be found). publisher = get_object_or_404(Publisher, name__iexact=name)
  • Notice that in the preceding example we passed the current publisher being displayed in the extra_context. This is usually a good idea in wrappers of this nature; it lets the template know which “parent” object is currently being browsed.
  • Or, you could use a less obvious but shorter version that relies on the fact that Book.objects.all is itself a callable:
pagetribe .

Chapter 8: Advanced Views and URLconfs - 0 views

  • Here, each view starts by checking that request.user is authenticated — that is, the current user has successfully logged into the site — and redirects to /accounts/login/ if not.
  • It would be nice if we could remove that bit of repetitive code from each of these views and just mark them as requiring authentication.
  • Now, we can remove the if not request.user.is_authenticated() checks from our views and simply wrap them with requires_login in our URLconf:
  • ...3 more annotations...
  • This has the same effect as before, but with less code redundancy. Now we’ve created a nice, generic function — requires_login() that we can wrap around any view in order to make it require login.
  • making a view wrapper.
  • There’s an important gotcha here: the regular expressions in this example that point to an include() do not have a $ (end-of-string match character) but do include a trailing slash.
  •  
    Here, each view starts by checking that request.user is authenticated - that is, the current user has successfully logged into the site - and redirects to /accounts/login/ if not.
« First ‹ Previous 81 - 100 Next › Last »
Showing 20 items per page