The [REGEX and IREGEX](http://docs.djangoproject.com/en/dev/ref/models/querysets/#iregex) operators were added in Django 1.0 and I'm sure you can think of fancier ways of doing word delimiting and things like that but this was all I needed to make a user-friendly autocomplete search function.
I don't understand why the cache is accumulated between the tests. I thought one of the axioms of unit testing is that the tests should not affect each other. Couldn't find anything that explains why it's done this way but it seems a bit strange. Anybody know if there's a reason or is this a reason for me to upload a patch to Django code?
Put that stuff in your settings.py Then you can use the git log last date to make that your "revision number" assuming you don't use regular version release numbers. With it you can do something like: <div id="footer"> © My Company — The Super App (revision {{ GIT_REVISION_DATE }}) </div> See if you like it
When debugging/developing you want to be able to refresh your views every time you make a little change. But when in production mode you might want to cache these views because they contain long and resource hungry calculations or something. By putting this above "hack" in after importing `cache_page` you only cache the views in production mode.
Install [sqlparse](http://code.google.com/p/python-sqlparse/) with `easy_install sqlparse` and then you can easily debug the SQL like this: def view(request): data = MyModel.objects.filter(something__very=complex) print_sql(data) ... Inspired by [Simon Willison](http://simonwillison.net/2009/Apr/28/)
If you have this as your base class for all unit tests you can do the following: class TestViews(BaseTestCase): def test_generated_stats(self): "test that certain stuff in the response" ...create some content for testing or use fixtures... response = self.client.get('/some/page/') # At this point response.content is a huge string filled with HTML tags and # "junk" that you don't need for testing the content thus making it difficult # to debug the generated HTML because it so huge. # So we can zoom in on the <div id="stats>...</div> node html = self._zoom_html(response.content, '#stats') # the variable 'html' will now be something like this: """ <div id="stats"> <p> <strong>2</strong> students<br/> <em>1</em> warning. </p> </div> """ # This makes it easier to debug the response and easier to test # against but the HTML might still be in the way so this would fail: self.assertTrue('2 students' in html) # will fail # To strip away all html use _strip_html() content = self._strip_html(html) # Now this will work self.assertTrue('2 students' in content) # will work It works for me and I find this very useful so I thought I'd share it.
This is a custom block tag and is used like this: {% load whitespaceoptimize %} {% whitespaceoptimize "css" %} /* CSS comment */ body { color: #CCCCCC; } {% endwhitespaceoptimize %} And when rendered you get this output: body{color:#CCC} To install it, download the snippet and call it `myapp/templatetags/whitespaceoptimize.py`. (Make sure you have a `__init__.py` in the `templatetags` directory) You need to download and install [slimmer](http://www.issuetrackerproduct.com/Download#slimmer) and put on your Python path. The block tag can be used for `javascript` and `html` as well as `css`. You can also let it guess the format; this would work for example: {% whitespaceoptimize %} <table> <tr> ... {% endwhitespaceoptimize %} ...but this would just replicate the functonality of the [built-in spaceless tag](http://docs.djangoproject.com/en/dev/ref/templates/builtins/#spaceless)