This is how you can access the user's request in the Form or FormSet definition, e.g. to define the choices of a ChoiceField dynamically. Either you use it for a single Form or a whole FormSet, just pass the view's request into the Form or FormSet instantiation.
I wanted to be able to limit which types of requests a view will accept. For instance, if a view only wants to deal with GET requests. @methods(GET) def index(request): # do stuff Now, calling this view with a non-GET request will cause a 403. You can easily change this to a 404, by using a different return function: which you may wish to do with openly available sites, as a 403 indicates there is a resource present.
This tag is designed to facilitate pagination in the case where both the page number and other parameters (eg. search criteria) are passed via GET. It takes one argument - a dictionary of GET variables to be added to the current url Example usage: {% for page_num in results.paginator.page_range %} <a href="{% append_to_get p=page_num %}">{{ page_num }}</a> {% endfor %} Note that the passed arguments are evaluated within the template context.
The django_admin_log only logs changes, not simple requests. Sometimes it can be useful to log when a user of your admin interface is checking out important data, for instance if you are making a system with personal sensitive data, that needs to comply with government / company policies. This will log such hits to the django_admin_log by overriding the change_view method in ModelAdmin. So you must override this method in all classes you want to have logged.
gets the value from request and returns it's boolean state
Add RequestMiddleware to your MIDDLEWARE_CLASSES settings Then, when you need request in special cases, call get_request(), which returns the request object. This has to be used in very special cases.
Get the referer view of a request. **Example:** def some_view(request): ... referer_view = get_referer_view(request) return HttpResponseRedirect(referer_view, '/accounts/login/')
This template tag takes the current GET query, and modifies or adds the value you specify. This is great for GET-query-driven views, where you want to provide URLs which reconfigure the view somehow. **Example Usage:** `{% get_string "sort_by" "date" %}` returns `all=your¤t=get&variables=plus&sort_by=date`
This is exacly the same snippet as #197 http://www.djangosnippets.org/snippets/197/ but returning search enigne, search engine domain and search term in: request.search_referrer_engine request.search_referrer_domain request.search_referrer_term I wanted to show ads only to people comming from search engines so I took snippet #197 and modify it to put that info in the request object.
Example: @limit("global", 3, 10, per_ip=True) def view(request, ...): The example limits the view to one request every 3 seconds per ip address. The limit is shared by every view that uses the string "global" (first parameter), which is an arbitrary string. Request succeed until the accumulated requested time in seconds (second parameter) exceeds the limit (third parameter).
As Simon Willison mentions in his [Debugging Django](http://simonwillison.net/2008/May/22/debugging/) presentation, using the Test Client in the interpreter can be a great way to take a peek at the raw results from a view. In some cases you may need to add additional headers to the request (for instance a piece of middleware may rely on them). Though it is not mentioned in the reference documentation, a quick peek at the code confirmed my hopes that it would be possible to add data to the request. The Client *get* and *post* methods both accept an **extra** kwargs parameter that allow you to populate the request with additional data.
A middleware that parses the HTTP_ACCEPT header of a request. The request gets a new method called "accepts" that takes a string and returns True if it was in the list of accepted mime-types. It makes it possible to write views like: def exampleview(request): if request.accepts('application/json'): # return a json representation if request.accepts('text/html'): # return html Please note that with this middleware the view defines the priority of the mime-types, not the order in which they where provided in the HTTP-Header.
Simply adds an attribute `is_ajax` to a request object, indicating if the request was made via Ajax. Allows you to reuse a lot of POST processing view code to which you'd like to progressively add Ajax: `if request.is_ajax: return JsonResponse(some_json)` `else: return render_to_response('some_template.html')`
This will return HTTP 405 if request was not POSTed. same way you can forbide POST request, change 'POST' to 'GET' Decorators provided for your convenience.
Here are a couple of Django decorators for limiting access to a view based on the request's `HTTP_REFERER`. Both raise a Django `PermissionDenied` exception if the referer test fails (or a referer simply isn't provided). The first, `referer_matches_hostname`, takes a hostname (and port, if specified) and matches it against the referer's. If multiple arguments are supplied a match against any of the hostnames will be considered valid. The second, `referer_matches_re`, takes a regex pattern (like Django's urlpattern) and tests if it matches the referer. This is obviously more flexible than `referer_matches_hostname` providing the ability to match not just the hostname, but any part of the referer url. Finally there's an simple example decorator, `local_referer_only`, that limits a view to the current site by using Django's `django.contrib.sites` to look up the current hostname.
30 snippets posted so far.