Login

Tag "urls"

29 snippets

Snippet List

Ajax form with jQuery

I recently got a form working via jQuery and Django. This was not easy for me to do and I thought I'd record my finding here. The form submits via jQuery and the "form" plugin. Please visit jQuery's home page to find all those links. This code handles: * urls.py -- passing both normal and 'Ajax' urls to a view. * views.py -- Handling both kinds of requests so that both normal and ajax submits will work. * The HTML template with the script for submitting and some bling. Error handling === I like to stay DRY so the idea of checking the form for errors in javascript *and* checking it in Django irks me. I decided to leave that up to Django, so the form submits and gets validated on the server. The error messages are sent back to the browser and then displayed.

  • ajax
  • urls
  • fields
  • views
  • jquery
  • form
  • errors
Read More

Decorating urlpatterns

One thing I wanted for a while was the ability to basically apply something like @login_required to a bunch of urlpatterns in one go, instead of having to decorate each and every view manually. In this example, the latter two views will always raise a 404.

  • urls
  • views
  • decorators
  • urlpatterns
Read More

Using reverse() to do redirects

When I initially set up my blog, I put together the archives with URL patterns like so: * `/weblog/2007/` goes to `archive_year` * `/weblog/2007/08/` goes to `archive_month` * `/weblog/2007/08/24/` goes to `archive_day` * `/weblog/2007/08/24/some-slug` goes to `object_detail` The same patterns held for links, only the prefix was `/links/` instead of `/weblog/`. For a forthcoming redesign/rewrite, I'm switching to using abbreviated month names (e.g., "aug", "sep", "oct", etc.) in the URLs, which means I need to redirect from the old-style URLs to the new. This snippet is the solution I hit upon. Two things are notable here: 1. Each one of these views uses [reverse()](http://www.djangoproject.com/documentation/url_dispatch/#reverse), called with the appropriate arguments, to generate the URL to redirect to. This means URLs don't have to be hard-coded in. 2. Each view takes an argument -- `object_type` -- which is used to generate the view name to pass to `reverse`, meaning that only one set of redirect views had to be written to handle both entries and links. This is just one of many handy tricks `reverse` can do :)

  • urls
  • reverse
  • redirects
Read More

Localized URLs (www-en)

An example on how we changed our localization middleware to use www-en.<domain> instead of it being hidden in the cookie. This also changes zh-cn to cn, and zh-tw to tw in the URLs. This is only a base snippet and you will most likely need to modify it to fit your needs.

  • internationalization
  • middleware
  • il8n
  • urls
Read More

@url decorator improvements

A slight modification (and, I think, improvement) of the URL decorator found in [snippet 395](http://www.djangosnippets.org/snippets/395/). What's different between this snippet and 395? 1. We use `django.conf.urls.defaults.url()` when adding patterns 2. We support arbitrary arguments to the `url()` method (like `name="foo"`) 3. We _do not_ support multiple url patterns (this didn't seem useful to me, but if it is I can add it back.)

  • urls
  • url
  • decorator
  • decorators
  • urlpatterns
Read More

Row-Level, URL-based permissions for FlatPages

I'm using Django's FlatPages, but I want to be able to restrict admin access to Users based on a FlatPage url. For example, User John Doe should be able to edit any FlatPage objects whose URL begins with `/johndoe/` (such as `/johndoe/about/` or `/johndoe/projects/whatever/`). For this to work, John Doe would already need the appropriate admin permissions for FlatPage (such as can_add and can_change). I have set this up as a separate *flatpage_addons* app. It consists of the **Permission** model, which maps a starting URL to one or more django Users. It consists of the minimal necessary admin code so Permissions can be created using the admin. The bulk of this code consists of the *ifhasflatpagepermission* template tag as well as the *flatpage_result_list* inclusion tag. The former works much like django's existing *if*, *else*, *endif* tags while the latter is modified from the django admin's *result_list* inclusion tag. This may not be the most elegant solution to my problem, but so far it works for me. Any comments or suggestions are welcome!

  • urls
  • url
  • permission
  • permissions
  • flatpage
  • flatpages
Read More

Never cache a group of URLs

This is a special URL patterns replacement that prevents caching of any URL listed within it. We needed this in Review Board to prevent the JSON API function results from being cached in Internet Explorer.

  • urls
  • cache
  • url
  • patterns
Read More

Automatic urls for static pages

Create in your template dir html files named example.static.html and with this snippet you can get the static page with the url /example/. If you put static file in a sub-directory, the url will be /sub-directory/example/ **Example:** `static_urls = StaticUrls()` `urlpatterns = patterns('', *static_urls.discover())` `urlpatterns += patterns('',` `(r'^admin/doc/', include('django.contrib.admindocs.urls')),` `(r'^admin/', include(admin.site.urls)),` `)`

  • urls
  • static
  • static files
  • url pattern
Read More

Conditional url pattern include

if_installed checks to see if the app is in installed apps. If it is not then it excludes it from being resolved in the url structure. In this example, myapp.urls will not be imported if myapp is not installed

  • urls
  • resolver
Read More

Allow any view (probably a generic view) to accept captured URL variables into extra_context.

If your URL pattern looks like: `urlpatterns = patterns('django.views.generic.create_update', url(r'^obj/(?P<obj_id>\d+)/new_thing$', create_object, {'form_class': ThingForm, 'template_name': 'thing/new_thing.html', extra_context: {:this":"that"}), )` You will receive an error, because the create_update view doesn't have a parameter called "obj_id". Supposing you want that variable in the URL, and furthermore let's say you wanted to do something with it in the template. With this function, you can wrap the view, and add the parameter capture_to_context, which maps URL variables to template variables: `urlpatterns = patterns('django.views.generic.create_update', url(r'^obj/(?P<obj_id>\d+)/new_thing$', view_url_vars_to_context(create_object), {'form_class': ThingForm, 'template_name': 'thing/new_thing.html', 'url_vars_to_context':{'obj_id':'objID'}, extra_context: {:this":"that"}}), )` Now objID will be a variable in your template, with the value given to obj_id. This is good for generic views, but there's no reason you couldn't use it for your own views if you really wanted, as long as you had an "extra_context" parameter.

  • urls
  • views
Read More