Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Edited docs/releases/1.2.txt

git-svn-id: http://code.djangoproject.com/svn/django/trunk@12123 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit 50bfa46c39d05d351ae77559d54fa8cab3e4f743 1 parent bf2283d
Adrian Holovaty authored January 09, 2010

Showing 1 changed file with 95 additions and 95 deletions. Show diff stats Hide diff stats

  1. 190  docs/releases/1.2.txt
190  docs/releases/1.2.txt
@@ -4,12 +4,12 @@
4 4
 Django 1.2 release notes — UNDER DEVELOPMENT
5 5
 ============================================
6 6
 
7  
-This page documents release notes for the as-yet-unreleased Django 1.2.  As such
8  
-it is tentative and subject to change.  It provides up-to-date information for
  7
+This page documents release notes for the as-yet-unreleased Django 1.2. As such,
  8
+it's tentative and subject to change. It provides up-to-date information for
9 9
 those who are following trunk.
10 10
 
11 11
 Django 1.2 includes a number of nifty `new features`_, lots of bug
12  
-fixes, and an easy upgrade path from Django 1.1.
  12
+fixes and an easy upgrade path from Django 1.1.
13 13
 
14 14
 .. _new features: `What's new in Django 1.2`_
15 15
 
@@ -21,22 +21,22 @@ Backwards-incompatible changes in 1.2
21 21
 CSRF Protection
22 22
 ---------------
23 23
 
24  
-There have been large changes to the way that CSRF protection works, detailed in
25  
-:ref:`the CSRF documentaton <ref-contrib-csrf>`.  The following are the major
26  
-changes that developers must be aware of:
  24
+We've made large changes to the way CSRF protection works, detailed in
  25
+:ref:`the CSRF documentaton <ref-contrib-csrf>`. Here are the major changes you
  26
+should be aware of:
27 27
 
28  
- * ``CsrfResponseMiddleware`` and ``CsrfMiddleware`` have been deprecated, and
  28
+ * ``CsrfResponseMiddleware`` and ``CsrfMiddleware`` have been deprecated and
29 29
    will be removed completely in Django 1.4, in favor of a template tag that
30 30
    should be inserted into forms.
31 31
 
32  
- * All contrib apps use a ``csrf_protect`` decorator to protect the view.  This
33  
-   requires the use of the csrf_token template tag in the template, so if you
  32
+ * All contrib apps use a ``csrf_protect`` decorator to protect the view. This
  33
+   requires the use of the csrf_token template tag in the template. If you
34 34
    have used custom templates for contrib views, you MUST READ THE :ref:`UPGRADE
35 35
    INSTRUCTIONS <ref-csrf-upgrading-notes>` to fix those templates.
36 36
 
37 37
  * ``CsrfViewMiddleware`` is included in :setting:`MIDDLEWARE_CLASSES` by
38  
-   default. This turns on CSRF protection by default, so that views that accept
39  
-   POST requests need to be written to work with the middleware.  Instructions
  38
+   default. This turns on CSRF protection by default, so views that accept
  39
+   POST requests need to be written to work with the middleware. Instructions
40 40
    on how to do this are found in the CSRF docs.
41 41
 
42 42
  * All of the CSRF has moved from contrib to core (with backwards compatible
@@ -46,32 +46,32 @@ changes that developers must be aware of:
46 46
 ----------------------
47 47
 
48 48
 Due to new features in the :ttag:`if` template tag, it no longer accepts 'and',
49  
-'or' and 'not' as valid **variable** names.  Previously that worked in some
50  
-cases even though these strings were normally treated as keywords.  Now, the
51  
-keyword status is always enforced, and template code like ``{% if not %}`` or
52  
-``{% if and %}`` will throw a TemplateSyntaxError.
  49
+'or' and 'not' as valid **variable** names. Previously, that worked in some
  50
+cases even though these strings were normally treated as keywords. Now, the
  51
+keyword status is always enforced, and template code such as ``{% if not %}`` or
  52
+``{% if and %}`` will throw a ``TemplateSyntaxError``.
53 53
 
54 54
 ``LazyObject``
55 55
 --------------
56 56
 
57 57
 ``LazyObject`` is an undocumented utility class used for lazily wrapping other
58  
-objects of unknown type.  In Django 1.1 and earlier, it handled introspection in
  58
+objects of unknown type. In Django 1.1 and earlier, it handled introspection in
59 59
 a non-standard way, depending on wrapped objects implementing a public method
60 60
 ``get_all_members()``. Since this could easily lead to name clashes, it has been
61 61
 changed to use the standard method, involving ``__members__`` and ``__dir__()``.
62  
-If you used ``LazyObject`` in your own code, and implemented the
  62
+If you used ``LazyObject`` in your own code and implemented the
63 63
 ``get_all_members()`` method for wrapped objects, you need to make the following
64 64
 changes:
65 65
 
66  
- * If your class does not have special requirements for introspection (i.e. you
  66
+ * If your class does not have special requirements for introspection (i.e., you
67 67
    have not implemented ``__getattr__()`` or other methods that allow for
68 68
    attributes not discoverable by normal mechanisms), you can simply remove the
69  
-   ``get_all_members()`` method.  The default implementation on ``LazyObject``
  69
+   ``get_all_members()`` method. The default implementation on ``LazyObject``
70 70
    will do the right thing.
71 71
 
72 72
  * If you have more complex requirements for introspection, first rename the
73  
-   ``get_all_members()`` method to ``__dir__()``.  This is the standard method,
74  
-   from Python 2.6 onwards, for supporting introspection.  If you are require
  73
+   ``get_all_members()`` method to ``__dir__()``. This is the standard method,
  74
+   from Python 2.6 onwards, for supporting introspection. If you require
75 75
    support for Python < 2.6, add the following code to the class::
76 76
 
77 77
        __members__ = property(lambda self: self.__dir__())
@@ -84,24 +84,21 @@ single database. Django 1.2 introduces support for multiple databases, and as
84 84
 a result, the way you define database settings has changed.
85 85
 
86 86
 Any existing Django settings file will continue to work as expected until
87  
-Django 1.4. Old-style database settings will be automatically translated to
88  
-the new-style format.
  87
+Django 1.4. Until then, old-style database settings will be automatically
  88
+translated to the new-style format.
89 89
 
90  
-In the old-style (pre 1.2) format, there were a number of
91  
-``DATABASE_`` settings at the top level of your settings file. For
92  
-example::
  90
+In the old-style (pre 1.2) format, you had a number of ``DATABASE_`` settings
  91
+in your settings file. For example::
93 92
 
94 93
     DATABASE_NAME = 'test_db'
95 94
     DATABASE_ENGINE = 'postgresql_psycopg2'
96 95
     DATABASE_USER = 'myusername'
97 96
     DATABASE_PASSWORD = 's3krit'
98 97
 
99  
-These settings are now contained inside a dictionary named
100  
-:setting:`DATABASES`. Each item in the dictionary corresponds to a
101  
-single database connection, with the name ``'default'`` describing the
102  
-default database connection. The setting names have also been
103  
-shortened to reflect the fact that they are stored in a dictionary.
104  
-The sample settings given previously would now be stored using::
  98
+These settings are now in a dictionary named :setting:`DATABASES`. Each item in
  99
+the dictionary corresponds to a single database connection, with the name
  100
+``'default'`` describing the default database connection. The setting names
  101
+have also been shortened. The previous sample settings would now look like this::
105 102
 
106 103
     DATABASES = {
107 104
         'default': {
@@ -138,7 +135,7 @@ must now be specified by a fully qualified module name (i.e.,
138 135
 ``django.db.backends.postgresql_psycopg2``, rather than just
139 136
 ``postgresql_psycopg2``).
140 137
 
141  
-``__dict__`` on Model instances
  138
+``__dict__`` on model instances
142 139
 -------------------------------
143 140
 
144 141
 Historically, the ``__dict__`` attribute of a model instance has only contained
@@ -148,12 +145,12 @@ In order to support multiple database configurations, Django 1.2 has
148 145
 added a ``_state`` attribute to object instances. This attribute will
149 146
 appear in ``__dict__`` for a model instance. If your code relies on
150 147
 iterating over __dict__ to obtain a list of fields, you must now
151  
-filter out ``_state`` attribute of out ``__dict__``.
  148
+filter the ``_state`` attribute of out ``__dict__``.
152 149
 
153  
-``get_db_prep_*()`` methods on Field
154  
-------------------------------------
  150
+``get_db_prep_*()`` methods on ``Field``
  151
+----------------------------------------
155 152
 
156  
-Prior to v1.2, a custom field had the option of defining several
  153
+Prior to 1.2, a custom ``Field`` had the option of defining several
157 154
 functions to support conversion of Python values into
158 155
 database-compatible values. A custom field might look something like::
159 156
 
@@ -190,25 +187,25 @@ two extra methods have been introduced::
190 187
         def get_db_prep_lookup(self, lookup_type, value, connection, prepared=False):
191 188
             # ...
192 189
 
193  
-These changes are required to support multiple databases -
  190
+These changes are required to support multiple databases --
194 191
 ``get_db_prep_*`` can no longer make any assumptions regarding the
195 192
 database for which it is preparing. The ``connection`` argument now
196 193
 provides the preparation methods with the specific connection for
197 194
 which the value is being prepared.
198 195
 
199  
-The two new methods exist to differentiate general data preparation
200  
-requirements, and requirements that are database-specific. The
201  
-``prepared`` argument is used to indicate to the database preparation
  196
+The two new methods exist to differentiate general data-preparation
  197
+requirements from requirements that are database-specific. The
  198
+``prepared`` argument is used to indicate to the database-preparation
202 199
 methods whether generic value preparation has been performed. If
203 200
 an unprepared (i.e., ``prepared=False``) value is provided to the
204 201
 ``get_db_prep_*()`` calls, they should invoke the corresponding
205 202
 ``get_prep_*()`` calls to perform generic data preparation.
206 203
 
207  
-Conversion functions has been provided which will transparently
  204
+We've provided conversion functions that will transparently
208 205
 convert functions adhering to the old prototype into functions
209  
-compatible with the new prototype. However, this conversion function
210  
-will be removed in Django 1.4, so you should upgrade your Field
211  
-definitions to use the new prototype.
  206
+compatible with the new prototype. However, these conversion functions
  207
+will be removed in Django 1.4, so you should upgrade your ``Field``
  208
+definitions to use the new prototype now, just to get it over with.
212 209
 
213 210
 If your ``get_db_prep_*()`` methods made no use of the database
214 211
 connection, you should be able to upgrade by renaming
@@ -227,7 +224,7 @@ template loader<template-loaders>`.
227 224
 
228 225
 All of the built-in Django template tags are safe to use with the cached
229 226
 loader, but if you're using custom template tags that come from third
230  
-party packages, or that you wrote yourself, you should ensure that the
  227
+party packages, or from your own code, you should ensure that the
231 228
 ``Node`` implementation for each tag is thread-safe. For more
232 229
 information, see
233 230
 :ref:`template tag thread safety considerations<template_tag_thread_safety>`.
@@ -236,10 +233,10 @@ Test runner exit status code
236 233
 ----------------------------
237 234
 
238 235
 The exit status code of the test runners (``tests/runtests.py`` and ``python
239  
-manage.py test``) no longer represents the number of failed tests, since a
240  
-failure of 256 or more tests resulted in a wrong exit status code.  The exit
  236
+manage.py test``) no longer represents the number of failed tests, because a
  237
+failure of 256 or more tests resulted in a wrong exit status code. The exit
241 238
 status code for the test runner is now 0 for success (no failing tests) and 1
242  
-for any number of test failures.  If needed, the number of test failures can be
  239
+for any number of test failures. If needed, the number of test failures can be
243 240
 found at the end of the test runner's output.
244 241
 
245 242
 .. _deprecated-features-1.2:
@@ -247,14 +244,14 @@ found at the end of the test runner's output.
247 244
 Features deprecated in 1.2
248 245
 ==========================
249 246
 
250  
-CSRF response rewriting middleware
  247
+CSRF response-rewriting middleware
251 248
 ----------------------------------
252 249
 
253 250
 ``CsrfResponseMiddleware``, the middleware that automatically inserted CSRF
254 251
 tokens into POST forms in outgoing pages, has been deprecated in favor of a
255 252
 template tag method (see above), and will be removed completely in Django
256 253
 1.4. ``CsrfMiddleware``, which includes the functionality of
257  
-``CsrfResponseMiddleware`` and ``CsrfViewMiddleware`` has likewise been
  254
+``CsrfResponseMiddleware`` and ``CsrfViewMiddleware``, has likewise been
258 255
 deprecated.
259 256
 
260 257
 Also, the CSRF module has moved from contrib to core, and the old imports are
@@ -264,7 +261,7 @@ deprecated, as described in the :ref:`upgrading notes <ref-csrf-upgrading-notes>
264 261
 ------------------
265 262
 
266 263
 The ``SMTPConnection`` class has been deprecated in favor of a generic
267  
-E-mail backend API. Old code that explicitly instantiated an instance
  264
+e-mail backend API. Old code that explicitly instantiated an instance
268 265
 of an SMTPConnection::
269 266
 
270 267
     from django.core.mail import SMTPConnection
@@ -272,7 +269,7 @@ of an SMTPConnection::
272 269
     messages = get_notification_email()
273 270
     connection.send_messages(messages)
274 271
 
275  
-should now call :meth:`~django.core.mail.get_connection()` to
  272
+...should now call :meth:`~django.core.mail.get_connection()` to
276 273
 instantiate a generic e-mail connection::
277 274
 
278 275
     from django.core.mail import get_connection
@@ -303,11 +300,11 @@ The API for storing messages in the user ``Message`` model (via
303 300
 ``user.message_set.create``) is now deprecated and will be removed in Django
304 301
 1.4 according to the standard :ref:`release process <internals-release-process>`.
305 302
 
306  
-To upgrade your code, you need to replace any instances of::
  303
+To upgrade your code, you need to replace any instances of this::
307 304
 
308 305
     user.message_set.create('a message')
309 306
 
310  
-with the following::
  307
+...with the following::
311 308
 
312 309
     from django.contrib import messages
313 310
     messages.add_message(request, messages.INFO, 'a message')
@@ -318,7 +315,7 @@ following::
318 315
     for message in user.get_and_delete_messages():
319 316
         ...
320 317
 
321  
-with::
  318
+...with::
322 319
 
323 320
     from django.contrib import messages
324 321
     for message in messages.get_messages(request):
@@ -333,24 +330,23 @@ Date format helper functions
333 330
 
334 331
 ``django.utils.translation.get_date_formats()`` and
335 332
 ``django.utils.translation.get_partial_date_formats()`` have been deprecated
336  
-in favor of the appropriate calls to ``django.utils.formats.get_format()``
337  
-which is locale aware when :setting:`USE_L10N` is set to ``True``, and falls
  333
+in favor of the appropriate calls to ``django.utils.formats.get_format()``,
  334
+which is locale-aware when :setting:`USE_L10N` is set to ``True``, and falls
338 335
 back to default settings if set to ``False``.
339 336
 
340  
-To get the different date formats, instead of writing::
  337
+To get the different date formats, instead of writing this::
341 338
 
342 339
     from django.utils.translation import get_date_formats
343 340
     date_format, datetime_format, time_format = get_date_formats()
344 341
 
345  
-use::
  342
+...use::
346 343
 
347 344
     from django.utils import formats
348  
-
349 345
     date_format = formats.get_format('DATE_FORMAT')
350 346
     datetime_format = formats.get_format('DATETIME_FORMAT')
351 347
     time_format = formats.get_format('TIME_FORMAT')
352 348
 
353  
-or, when directly formatting a date value::
  349
+Or, when directly formatting a date value::
354 350
 
355 351
     from django.utils import formats
356 352
     value_formatted = formats.date_format(value, 'DATETIME_FORMAT')
@@ -372,13 +368,13 @@ CSRF support
372 368
 Django now has much improved protection against :ref:`Cross-Site
373 369
 Request Forgery (CSRF) attacks<ref-contrib-csrf>`. This type of attack
374 370
 occurs when a malicious Web site contains a link, a form button or
375  
-some javascript that is intended to perform some action on your Web
  371
+some JavaScript that is intended to perform some action on your Web
376 372
 site, using the credentials of a logged-in user who visits the
377  
-malicious site in their browser. A related type of attack, 'login
378  
-CSRF', where an attacking site tricks a user's browser into logging
  373
+malicious site in their browser. A related type of attack, "login
  374
+CSRF," where an attacking site tricks a user's browser into logging
379 375
 into a site with someone else's credentials, is also covered.
380 376
 
381  
-E-mail Backends
  377
+E-mail backends
382 378
 ---------------
383 379
 
384 380
 You can now :ref:`configure the way that Django sends e-mail
@@ -389,14 +385,14 @@ sending mail, you can now construct an e-mail backend that will allow
389 385
 Django's standard :ref:`mail sending methods<topics-email>` to use
390 386
 those facilities.
391 387
 
392  
-This also makes it easier to debug mail sending - Django ships with
  388
+This also makes it easier to debug mail sending. Django ships with
393 389
 backend implementations that allow you to send e-mail to a
394 390
 :ref:`file<topic-email-file-backend>`, to the
395 391
 :ref:`console<topic-email-console-backend>`, or to
396  
-:ref:`memory<topic-email-memory-backend>` - you can even configure all
  392
+:ref:`memory<topic-email-memory-backend>`. You can even configure all
397 393
 e-mail to be :ref:`thrown away<topic-email-dummy-backend>`.
398 394
 
399  
-Messages Framework
  395
+Messages framework
400 396
 ------------------
401 397
 
402 398
 Django now includes a robust and configurable :ref:`messages framework
@@ -412,14 +408,14 @@ Support for multiple databases
412 408
 Django 1.2 adds the ability to use :ref:`more than one database
413 409
 <topics-db-multi-db>` in your Django project. Queries can be
414 410
 issued at a specific database with the `using()` method on
415  
-querysets; individual objects can be saved to a specific database
416  
-by providing a ``using`` argument when you save the instance.
  411
+``QuerySet`` objects. Individual objects can be saved to a specific database
  412
+by providing a ``using`` argument when you call ``save()``.
417 413
 
418 414
 'Smart' if tag
419 415
 --------------
420 416
 
421  
-The :ttag:`if` tag has been upgraded to be much more powerful.  First, support
422  
-for comparison operators has been added. No longer will you have to type:
  417
+The :ttag:`if` tag has been upgraded to be much more powerful. First, we've
  418
+added support for comparison operators. No longer will you have to type:
423 419
 
424 420
 .. code-block:: html+django
425 421
 
@@ -427,7 +423,7 @@ for comparison operators has been added. No longer will you have to type:
427 423
      ...
428 424
     {% endifnotequal %}
429 425
 
430  
-...as you can now do:
  426
+You can now do this::
431 427
 
432 428
 .. code-block:: html+django
433 429
 
@@ -435,9 +431,12 @@ for comparison operators has been added. No longer will you have to type:
435 431
      ...
436 432
     {% endif %}
437 433
 
  434
+There's really no reason to use ``{% ifequal %}`` or ``{% ifnotequal %}``
  435
+anymore, unless you're the nostalgic type.
  436
+
438 437
 The operators supported are ``==``, ``!=``, ``<``, ``>``, ``<=``, ``>=`` and
439 438
 ``in``, all of which work like the Python operators, in addition to ``and``,
440  
-``or`` and ``not`` which were already supported.
  439
+``or`` and ``not``, which were already supported.
441 440
 
442 441
 Also, filters may now be used in the ``if`` expression. For example:
443 442
 
@@ -452,10 +451,10 @@ Also, filters may now be used in the ``if`` expression. For example:
452 451
 Template caching
453 452
 ----------------
454 453
 
455  
-In previous versions of Django, every time you rendered a template it
  454
+In previous versions of Django, every time you rendered a template, it
456 455
 would be reloaded from disk. In Django 1.2, you can use a :ref:`cached
457  
-template loader <template-loaders>` to load templates once, then use a
458  
-cached the result for every subsequent render. This can lead to a
  456
+template loader <template-loaders>` to load templates once, then
  457
+cache the result for every subsequent render. This can lead to a
459 458
 significant performance improvement if your templates are broken into
460 459
 lots of smaller subtemplates (using the ``{% extends %}`` or ``{%
461 460
 include %}`` tags).
@@ -467,48 +466,49 @@ non-Django template languages<topic-template-alternate-language>`.
467 466
 Natural keys in fixtures
468 467
 ------------------------
469 468
 
470  
-Fixtures can refer to remote objects using
  469
+Fixtures can now refer to remote objects using
471 470
 :ref:`topics-serialization-natural-keys`. This lookup scheme is an
472 471
 alternative to the normal primary-key based object references in a
473  
-fixture, improving readability, and resolving problems referring to
  472
+fixture, improving readability and resolving problems referring to
474 473
 objects whose primary key value may not be predictable or known.
475 474
 
476 475
 ``BigIntegerField``
477 476
 -------------------
478 477
 
479  
-Models can now use a 64 bit :class:`~django.db.models.BigIntegerField` type.
  478
+Models can now use a 64-bit :class:`~django.db.models.BigIntegerField` type.
480 479
 
481  
-Fast Failure for Tests
  480
+Fast failure for tests
482 481
 ----------------------
483 482
 
484  
-The :djadmin:`test` subcommand of ``django-admin.py``, and the ``runtests.py``
485  
-script used to run Django's own test suite, support a new ``--failfast`` option.
  483
+Both the :djadmin:`test` subcommand of ``django-admin.py`` and the ``runtests.py``
  484
+script used to run Django's own test suite now support a ``--failfast`` option.
486 485
 When specified, this option causes the test runner to exit after encountering
487  
-a failure instead of continuing with the test run.  In addition, the handling
  486
+a failure instead of continuing with the test run. In addition, the handling
488 487
 of ``Ctrl-C`` during a test run has been improved to trigger a graceful exit
489  
-from the test run that reports details of the tests run before the interruption.
  488
+from the test run that reports details of the tests that were run before the
  489
+interruption.
490 490
 
491 491
 Improved localization
492 492
 ---------------------
493 493
 
494 494
 Django's :ref:`internationalization framework <topics-i18n>` has been
495  
-expanded by locale aware formatting and form processing. That means, if
  495
+expanded with locale-aware formatting and form processing. That means, if
496 496
 enabled, dates and numbers on templates will be displayed using the format
497 497
 specified for the current locale. Django will also use localized formats
498  
-when parsing data in forms.
499  
-See :ref:`Format localization <format-localization>` for more details.
  498
+when parsing data in forms. See
  499
+:ref:`Format localization <format-localization>` for more details.
500 500
 
501  
-Added ``readonly_fields`` to ``ModelAdmin``
502  
--------------------------------------------
  501
+``readonly_fields`` in ``ModelAdmin``
  502
+-------------------------------------
503 503
 
504 504
 :attr:`django.contrib.admin.ModelAdmin.readonly_fields` has been added to
505 505
 enable non-editable fields in add/change pages for models and inlines. Field
506  
-and calculated values can be displayed along side editable fields.
  506
+and calculated values can be displayed alongside editable fields.
507 507
 
508 508
 Customizable syntax highlighting
509 509
 --------------------------------
510 510
 
511  
-You can now use the ``DJANGO_COLORS`` environment variable to modify
  511
+You can now use a ``DJANGO_COLORS`` environment variable to modify
512 512
 or disable the colors used by ``django-admin.py`` to provide
513 513
 :ref:`syntax highlighting <syntax-coloring>`.
514 514
 
@@ -516,9 +516,9 @@ Model validation
516 516
 ----------------
517 517
 
518 518
 Model instances now have support for :ref:`validating their own data
519  
-<validating-objects`, and both model and form fields now accept
  519
+<validating-objects>`, and both model and form fields now accept
520 520
 configurable lists of :ref:`validators <ref-validators>` specifying
521 521
 reusable, encapsulated validation behavior. Note, however, that
522  
-validation must still be performed explicitly: simply invoking a model
  522
+validation must still be performed explicitly. Simply invoking a model
523 523
 instance's ``save()`` method will not perform any validation of the
524 524
 instance's data.

0 notes on commit 50bfa46

Please sign in to comment.
Something went wrong with that request. Please try again.