What will happen in django 1.3

Release django 1.3 very soon. I think many already use RC in production. But still, I’ll go over what’s waiting for us, trying not to slip into the translation of the release notes.

django.contrib.staticfiles

Now you can organize static (pictures, js, css, etc.) just like templates are organized: keep it in the application folder (especially useful for individual django applications) or in the project folder, override some files, leaving others intact , to link to files, not caring about where the user will put them or where they are stored (separate server? amazon s3?), you no longer need to “finger out” these files and copy them to the right place.

Dirty khaki with statics for admin panel now, too, can be considered in the past - if you just use django.contrib.staticfiles, there will be no problems.
')

Testing

Unittest2 now lives in janga , django.test.TestCase is inherited from unittest2.TestCase. This means that you can write tests for jungles using all the new features from unittest2. For example, you can write tests in advance and mark them with the expectedFailure decorator. Or specify the conditions under which tests should be skipped (for example, tests that are specific to mysql and should not pass under sqlite). Or use new assertions.

Of course, before you could put unittest2 and use it, but it did not help when you needed a base and you had to inherit from django.test.TestCase.

There were also various useful things like assertNumQueries.

ForeignKey

Hooray, now when deleting an object that someone referred to via FK, the referencing objects will not necessarily be deleted. You can configure a cascade delete, reset to NULL or the default value, call an exception, do nothing (let the database decide itself).

Templates

Often wrote

{% with foo as bar %} {% include "my_template.inc.html" %} {% endwith %} 

or inclusion tags for such items? Now it is not necessary, and a bunch of inclusion tags can be thrown out:

 {% include "my_template.inc.html" with bar=foo %} 

+ you can download only individual tags from tag libraries; variables can be passed to the url; the with tag is also simplified; tags created through simple_tag have learned to take context.

Caching

There was support for several caches at the same time (for example, some data can be stored in localmem-cache, some - in memcached / database, or for some things use “smart” caching backends with disability and protection from simultaneous regeneration, for others - no).

In addition, from various third-party applications with caching backends useful features crawled into janga: now out of the box there is support for a global prefix (needed if several projects use 1 memcached to avoid key conflicts), cache versions (updated site, and old data in cache lie, which are now in the wrong format? increase the current version of the cache), key conversions (need a clever invalidation scheme? implement), pylibmc support, caching for GET requests with parameters.

Journaling

Integration with Python logging is now there. In settings.py, logging can be flexibly configured. Email sending for 500 errors is also done via logging.

Views

For writing views there are a bunch of different utilities.

Class-based views.

You can now write view classes. For myself, I still do not understand why they are. Probably should be used for some "big" pieces, or when some complicated thing with confused logic that needs to be expanded in other places (declarative api? Something of the level of a universal admin?). Standard generic views are now rewritten on classes to make it easier to expand.

TemplateResponse

In order to be able to extend regular view functions, there is now a TemplateResponse in jang. TemplateResponse is a lazy HttpResponse that renders the result (inserts the context into the template) only at the very last moment. If the function returns a TemplateResponse, then it can then replace the template, change (and read) the context, or return something completely different (without the overhead of rendering the original response). It’s pretty easy to skip this thing in release notes and start for flexibility in wrapping views on classes, so an example:

 #      #          from django.template.response import TemplateResponse from parrots.models import Parrot def parrot_list(request): parrots = Parrot.objects.all() #     RequestContext. #   render_to_template    direct_to_template   . return TemplateResponse(request, 'parrots.html', {'parrots': parrots}) 

 #  . # parrot_list       ( ,   ),  #    ,      import parrots.views def parrot_list(request, color) # ,      response = parrots.views.parrot_list(request) #        (TemplateResponse ), #        (QuerySet  ) #     - ,     ,     response.template_name = 'my_parrots.html' #    original_parrots = response.context_data['parrots'] #    ,       response.context_data['parrots'] = original_parrots.filter(color=color).select_related('owner') #  -     response.context_data['foo'] = 'bar' #       return response 

Generic views now return a TemplateResponse by default, views from django.contrib.admin too .
UPD : Took wishful thinking, django.contrib.admin TemplateResponse views are not returned! The ticket hangs, but it is not committed to release.

django.shortcuts.render

 #   ,      from django.shortcuts import render def parrot_list(request): parrots = Parrot.objects.all() # render_to_response  direct_to_template    return render(request, 'parrots.html', {'parrots': parrots}) 

This is not all: except for these changes, the work with i18n and l10n has been improved, the entire mat has been removed from the code, and many other less noticeable changes and architectural improvements, some of which can be found in release notes .