An example of using it in your settings.py:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.doc.XViewMiddleware',
'util.loginmiddleware.RequireLoginMiddleware',
)
LOGIN_REQUIRED_URLS = (
r'/payment/(.*)$',
r'/accounts/home/(.*)$',
r'/accounts/edit-account/(.*)$',
)
In a nutshell this requires the user to login for any url that matches against whats listing in LOGIN_REQUIRED_URLS. The system will redirect to [LOGIN_URL](http://www.djangoproject.com/documentation/settings/#login-url)
- middleware
- authentication
- url
- login
- auth
Django's test client is very limited when it comes to testing complex interactions e.g. forms with hidden or persisted values etc. Twill excels in this area, and thankfully it is very easy to integrate it.
* Use `twill_setup` in your `TestCaseSubClass.setUp()` method
* Use `twill_teardown` in `TestCaseSubClass.tearDown()` method
* In a test, use something like `make_twill_url()` to generate URLs that will work for twill.
* Use `twill.commands.go()` etc. to control twill, or use `twill.execute_string()` or `twill.execute_script()`.
* Add `twill.set_output(StringIO())` to suppress twill output
* If you want to write half the test, then use twill interactively to write the rest as a twill script, use the example in `unfinished_test()`
Twill will raise exceptions if commands fail. This means you will get 'E' for error, rather than 'F' for fail in the test output. If necessary, it wouldn't be hard to wrap the twill commands to flag failure with TestCase.assert_
There are, of course, more advanced ways of using these functions (e.g. a mixin that does the setup/teardown for you), but the basic functions needed are here.
See also:
* [Twill](http://twill.idyll.org/)
* [Twill Python API](http://twill.idyll.org/python-api.html)
Adds filtering by ranges of values in the admin filter sidebar. This allows rows in numerical fields to be grouped together (in this case, group by price):
By store price
All
< 100
100 - 200
200 - 500
500 - 2000
>= 200
**To use:**
1. save the code as rangevaluesfilterspec.py in your app's directory
2. add `import rangevaluesfilterspec` to your models.py
3. add `myfield.list_filter_range = [value1, value2, ...]` to your filter field
**Example:**
from django.db import models
import rangevaluesfilterspec
class Product(models.Model):
store_price = models.DecimalField(max_digits=10, decimal_places=2)
store_price.list_filter_range = [100, 200, 500, 2000]
class Admin:
list_filter = ['store_price']
Note that two extra groups are added: less-than the lowest value, and greater-than-or-equal-to the highest value.
This view decorator renders automaticaly the template with the context provided both by the view "return" statement. For example:
@auto_render
def my_view(request):
...
return 'base.html', locals()
You can still return HttpResponse and HttpResponseRedirect objects without any problems. If you use Ajax requests, this decorator is even more useful. Imagine this layout:
def aggregating_view(request):
...
context = locals()
partial1 = partial_view_1(request, only_context=True)
partial2 = partial_view_2(request, only_context=True)
# aggregate template include partial templates
return 'aggregate.htmt', context.update(partial1).update(partial2)
def partial_view_1(request):
...
return 'partial_1.html', locals()
def partial_view_2(request):
...
return 'partial_2.html', locals()
This way you can render you view individualy for specific ajax calls and also get their context for the aggregating view.
- render_to_response
- ajax
- decorator
- rendering