[Changeset] r14404 - django/branches/releases/1.2.X/docs/topics

[noreply]

Author: ramiro
Date: 2010-10-30 21:35:18 -0500 (Sat, 30 Oct 2010)
New Revision: 14404

Modified:
   django/branches/releases/1.2.X/docs/topics/auth.txt
Log:
[1.2.X] Fixed #13503 -- Corrected misleading custom permission example in the 
docs.

Thanks Daniel Moisset for the report.

Backport of [14403] from trunk

Modified: django/branches/releases/1.2.X/docs/topics/auth.txt
===
--- django/branches/releases/1.2.X/docs/topics/auth.txt 2010-10-31 02:34:01 UTC 
(rev 14403)
+++ django/branches/releases/1.2.X/docs/topics/auth.txt 2010-10-31 02:35:18 UTC 
(rev 14404)
@@ -1181,19 +1181,23 @@
 To create custom permissions for a given model object, use the ``permissions``
 :ref:`model Meta attribute `.
 
-This example model creates three custom permissions::
+This example Task model creates three custom permissions, i.e., actions users
+can or cannot do with Task instances, specific to your appication::
 
-class USCitizen(models.Model):
-# ...
+class Task(models.Model):
+...
 class Meta:
 permissions = (
-("can_drive", "Can drive"),
-("can_vote", "Can vote in elections"),
-("can_drink", "Can drink alcohol"),
+("can_view", "Can see available tasks"),
+("can_change_status", "Can change the status of tasks"),
+("can_close", "Can remove a task by setting its status as 
closed"),
 )
 
 The only thing this does is create those extra permissions when you run
-:djadmin:`manage.py syncdb `.
+:djadmin:`manage.py syncdb `. Your code is in charge of checking the
+value of these permissions when an user is trying to access the functionality
+provided by the application (viewing tasks, changing the status of tasks,
+closing tasks.)
 
 API reference
 -

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r14403 - django/trunk/docs/topics

[noreply]

Author: ramiro
Date: 2010-10-30 21:34:01 -0500 (Sat, 30 Oct 2010)
New Revision: 14403

Modified:
   django/trunk/docs/topics/auth.txt
Log:
Fixed #13503 -- Corrected misleading custom permission example in the docs.

Thanks Daniel Moisset for the report.

Modified: django/trunk/docs/topics/auth.txt
===
--- django/trunk/docs/topics/auth.txt   2010-10-31 00:53:58 UTC (rev 14402)
+++ django/trunk/docs/topics/auth.txt   2010-10-31 02:34:01 UTC (rev 14403)
@@ -1197,19 +1197,23 @@
 To create custom permissions for a given model object, use the ``permissions``
 :ref:`model Meta attribute `.
 
-This example model creates three custom permissions::
+This example Task model creates three custom permissions, i.e., actions users
+can or cannot do with Task instances, specific to your appication::
 
-class USCitizen(models.Model):
-# ...
+class Task(models.Model):
+...
 class Meta:
 permissions = (
-("can_drive", "Can drive"),
-("can_vote", "Can vote in elections"),
-("can_drink", "Can drink alcohol"),
+("can_view", "Can see available tasks"),
+("can_change_status", "Can change the status of tasks"),
+("can_close", "Can remove a task by setting its status as 
closed"),
 )
 
 The only thing this does is create those extra permissions when you run
-:djadmin:`manage.py syncdb `.
+:djadmin:`manage.py syncdb `. Your code is in charge of checking the
+value of these permissions when an user is trying to access the functionality
+provided by the application (viewing tasks, changing the status of tasks,
+closing tasks.)
 
 API reference
 -

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #7596: Multiple Database Inserts using 1 query

[Django]

#7596: Multiple Database Inserts using 1 query
---+
  Reporter:  erikcw| Owner:  nobody 

Status:  new   | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  database, 
create, multirow, feature
 Stage:  Accepted  | Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by carljm):

  * stage:  Design decision needed => Accepted

Comment:

 The API here still requires design discussion, but accepting this in
 principle.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #7596: Multiple Database Inserts using 1 query

[Django]

#7596: Multiple Database Inserts using 1 query
---+
  Reporter:  erikcw| Owner:  nobody 

Status:  new   | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  database, 
create, multirow, feature
 Stage:  Design decision needed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Comment (by carljm):

 This came up just now in discussing optimizing the Django test suite. A
 lot of time in !TransactionTestCases is wasted in model-by-model
 get_or_create of content-types and permissions. As it stands, the lookups
 there could be optimized, but to fully optimize it a bulk-insert ORM
 operation would also be needed.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r14402 - in django/trunk/django: core/management core/management/commands db/backends db/backends/sqlite3

[noreply]

Author: Alex
Date: 2010-10-30 19:53:58 -0500 (Sat, 30 Oct 2010)
New Revision: 14402

Modified:
   django/trunk/django/core/management/commands/flush.py
   django/trunk/django/core/management/sql.py
   django/trunk/django/db/backends/__init__.py
   django/trunk/django/db/backends/sqlite3/introspection.py
Log:
When looking for django tables which exist, query for all tables once, not once 
*per table*.

Modified: django/trunk/django/core/management/commands/flush.py
===
--- django/trunk/django/core/management/commands/flush.py   2010-10-30 
23:39:53 UTC (rev 14401)
+++ django/trunk/django/core/management/commands/flush.py   2010-10-31 
00:53:58 UTC (rev 14402)
@@ -9,7 +9,6 @@
 from django.utils.importlib import import_module
 
 
-
 class Command(NoArgsCommand):
 option_list = NoArgsCommand.option_list + (
 make_option('--noinput', action='store_false', dest='interactive', 
default=True,

Modified: django/trunk/django/core/management/sql.py
===
--- django/trunk/django/core/management/sql.py  2010-10-30 23:39:53 UTC (rev 
14401)
+++ django/trunk/django/core/management/sql.py  2010-10-31 00:53:58 UTC (rev 
14402)
@@ -111,7 +111,9 @@
 tables = 
connection.introspection.django_table_names(only_existing=True)
 else:
 tables = connection.introspection.table_names()
-statements = connection.ops.sql_flush(style, tables, 
connection.introspection.sequence_list())
+statements = connection.ops.sql_flush(
+style, tables, connection.introspection.sequence_list()
+)
 return statements
 
 def sql_custom(app, style, connection):

Modified: django/trunk/django/db/backends/__init__.py
===
--- django/trunk/django/db/backends/__init__.py 2010-10-30 23:39:53 UTC (rev 
14401)
+++ django/trunk/django/db/backends/__init__.py 2010-10-31 00:53:58 UTC (rev 
14402)
@@ -615,7 +615,12 @@
 tables.add(model._meta.db_table)
 tables.update([f.m2m_db_table() for f in 
model._meta.local_many_to_many])
 if only_existing:
-tables = [t for t in tables if self.table_name_converter(t) in 
self.table_names()]
+existing_tables = self.table_names()
+tables = [
+t
+for t in tables
+if self.table_name_converter(t) in existing_tables
+]
 return tables
 
 def installed_models(self, tables):

Modified: django/trunk/django/db/backends/sqlite3/introspection.py
===
--- django/trunk/django/db/backends/sqlite3/introspection.py2010-10-30 
23:39:53 UTC (rev 14401)
+++ django/trunk/django/db/backends/sqlite3/introspection.py2010-10-31 
00:53:58 UTC (rev 14402)
@@ -4,7 +4,7 @@
 # This light wrapper "fakes" a dictionary interface, because some SQLite data
 # types include variables in them -- e.g. "varchar(30)" -- and can't be matched
 # as a simple dictionary lookup.
-class FlexibleFieldLookupDict:
+class FlexibleFieldLookupDict(object):
 # Maps SQL types to Django Field types. Some of the SQL types have multiple
 # entries here because SQLite allows for anything and doesn't normalize the
 # field type; it uses whatever was given.
@@ -138,4 +138,3 @@
  'null_ok': not field[3],
  'pk': field[5] # undocumented
  } for field in cursor.fetchall()]
-

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r14401 - in django/trunk: django/contrib/staticfiles/management/commands tests/regressiontests/staticfiles_tests

[noreply]

Author: Alex
Date: 2010-10-30 18:39:53 -0500 (Sat, 30 Oct 2010)
New Revision: 14401

Modified:
   django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
   django/trunk/tests/regressiontests/staticfiles_tests/tests.py
Log:
Ensure that the staticfiles tests use the MEDIA_ROOT they intended, also use a 
more approrpiate datastructure in collectstatic.

Modified: 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
===
--- 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
2010-10-30 13:04:02 UTC (rev 14400)
+++ 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
2010-10-30 23:39:53 UTC (rev 14401)
@@ -39,9 +39,9 @@
 if options['use_default_ignore_patterns']:
 ignore_patterns += ['CVS', '.*', '*~']
 ignore_patterns = list(set(ignore_patterns))
-self.copied_files = []
-self.symlinked_files = []
-self.unmodified_files = []
+self.copied_files = set()
+self.symlinked_files = set()
+self.unmodified_files = set()
 self.destination_storage = 
get_storage_class(settings.STATICFILES_STORAGE)()
 
 try:
@@ -124,14 +124,14 @@
 # storage doesn't support ``modified_time`` or failed.
 pass
 else:
-destination_is_link= os.path.islink(
+destination_is_link = os.path.islink(
 self.destination_storage.path(destination))
 if destination_last_modified == source_last_modified:
 if (not symlink and not destination_is_link):
 if verbosity >= 2:
 self.stdout.write("Skipping '%s' (not modified)\n"
   % destination)
-self.unmodified_files.append(destination)
+self.unmodified_files.add(destination)
 return False
 if dry_run:
 if verbosity >= 2:
@@ -157,7 +157,7 @@
 except OSError:
 pass
 os.symlink(source_path, destination_path)
-self.symlinked_files.append(destination)
+self.symlinked_files.add(destination)
 else:
 if dry_run:
 if verbosity >= 1:
@@ -180,5 +180,5 @@
 if verbosity >= 1:
 self.stdout.write("Copying %s to %s\n"
   % (source_path, destination))
-self.copied_files.append(destination)
+self.copied_files.add(destination)
 return True

Modified: django/trunk/tests/regressiontests/staticfiles_tests/tests.py
===
--- django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2010-10-30 13:04:02 UTC (rev 14400)
+++ django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2010-10-30 23:39:53 UTC (rev 14401)
@@ -7,12 +7,13 @@
 
 from django.test import TestCase
 from django.conf import settings
+from django.contrib.staticfiles import finders, storage
+from django.core.files.storage import default_storage
 from django.core.exceptions import ImproperlyConfigured
 from django.core.management import call_command
 from django.db.models.loading import load_app
 from django.template import Template, Context
 
-from django.contrib.staticfiles import finders, storage
 
 TEST_ROOT = os.path.dirname(__file__)
 
@@ -54,6 +55,11 @@
 "regressiontests.staticfiles_tests",
 ]
 
+# Clear the cached default_storage out, this is because when it first
+# gets accessed (by some other test), it evaluates settings.MEDIA_ROOT,
+# since we're planning on changing that we need to clear out the cache.
+default_storage._wrapped = None
+
 def tearDown(self):
 settings.DEBUG = self.old_debug
 settings.MEDIA_ROOT = self.old_media_root

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12248: django.template.__init__ code should move to avoid circular imports

[Django]

#12248: django.template.__init__ code should move to avoid circular imports
--+-
  Reporter:  tomxtobin| Owner:  nobody
Status:  new  | Milestone:
 Component:  Template system  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Changes (by tomxtobin):

 * cc: korp...@korpios.com (removed)
 * cc: tomxto...@tomxtobin.com (added)
  * reporter:  korpios => tomxtobin

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14446: auth.views.password_reset_confirm should never be cached

[Django]

#14446: auth.views.password_reset_confirm should never be cached
+---
  Reporter:  PaulM  | Owner:  PaulM
Status:  new| Milestone:  1.3  
 Component:  Authentication |   Version:  1.2  
Resolution: |  Keywords:   
 Stage:  Ready for checkin  | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Ready for checkin
  * needs_tests:  => 0
  * needs_docs:  => 0

Old description:

> I'm splitting this issue off from #14105, as it is separate from the meat
> of that ticket.
>
> `Django.contrib.auth.views.password_reset_confirm` needs the
> `never_cache` decorator.
>
> To reproduce:
> {{{
> 1. Start a new project. Add  django.contrib.admin  and setup a sqlite
> database. Test result: OK.
>
> 2. Add the required cache settings and the update/fetch middleware. Tests
> result: FAILED (failures=1, errors=27)
> }}}
>
> This issue is that single failure.

New description:

 I'm splitting this issue off from #14105, as it is separate from the meat
 of that ticket.

 `Django.contrib.auth.views.password_reset_confirm` needs the `never_cache`
 decorator.

 To reproduce:
 {{{
 1. Start a new project. Add  django.contrib.admin  and setup a sqlite
 database. Run manage.py test auth. Result: OK.

 2. Relevant bits of settings.py:

 MIDDLEWARE_CLASSES = (
 'django.middleware.cache.UpdateCacheMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.cache.FetchFromCacheMiddleware,
 )
 CACHE_BACKEND = 'locmem://'

 Run manage.py test auth. Result: (failures=1, errors=11)
 }}}

 This issue is that single failure.

Comment:

 I can confirm that this patch fixes this test failure, specifically:

 {{{
 ==
 FAIL: test_confirm_valid
 (django.contrib.auth.tests.views.PasswordResetTest)
 --
 Traceback (most recent call last):
   File "C:\Development\django\trunk\django\contrib\auth\tests\views.py",
 line 91, in test_confirm_valid
 self.assert_("Please enter your new password" in response.content)
 AssertionError: False is not True

 --
 }}}

 The other 11 errors remaining when running the tests under these
 conditions are still related to #14105.

 Updated the description to make it easier to duplicate if anyone else
 wants to check it prior to committing. Marking as RFC.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11870: Moderation doesn't work with comments extended from BaseCommentAbstractModel

[Django]

#11870: Moderation doesn't work with comments extended from
BaseCommentAbstractModel
--+-
  Reporter:  HM   | Owner:  nobody
Status:  new  | Milestone:
 Component:  django.contrib.comments  |   Version:  SVN   
Resolution:   |  Keywords:  moderation
 Stage:  Accepted | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  1 
Needs_better_patch:  0|  
--+-
Changes (by unbracketed):

 * cc: br...@lincolnloop.com (added)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r14400 - django/trunk/tests/regressiontests/test_utils

[noreply]

Author: russellm
Date: 2010-10-30 08:04:02 -0500 (Sat, 30 Oct 2010)
New Revision: 14400

Modified:
   django/trunk/tests/regressiontests/test_utils/python_25.py
Log:
Rewrote a test assertion so that it doesn't fail under Python 2.7. Thanks to 
Florian Apolloner for the report.

Modified: django/trunk/tests/regressiontests/test_utils/python_25.py
===
--- django/trunk/tests/regressiontests/test_utils/python_25.py  2010-10-30 
13:03:37 UTC (rev 14399)
+++ django/trunk/tests/regressiontests/test_utils/python_25.py  2010-10-30 
13:04:02 UTC (rev 14400)
@@ -21,7 +21,7 @@
 with self.assertRaises(AssertionError) as exc_info:
 with self.assertNumQueries(2):
 Person.objects.count()
-self.assertEqual(str(exc_info.exception), "1 != 2 : 1 queries 
executed, 2 expected")
+self.assertIn("1 queries executed, 2 expected", 
str(exc_info.exception))
 
 with self.assertRaises(TypeError):
 with self.assertNumQueries(4000):

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r14399 - django/trunk/django/test

[noreply]

Author: russellm
Date: 2010-10-30 08:03:37 -0500 (Sat, 30 Oct 2010)
New Revision: 14399

Modified:
   django/trunk/django/test/testcases.py
Log:
Reordered the shutdown process for tests so that all tests force a connection 
close. This is required to prevent some cross-test failures. Thanks to Florian 
Apolloner for the report and help tracking down the problem.

Modified: django/trunk/django/test/testcases.py
===
--- django/trunk/django/test/testcases.py   2010-10-30 07:19:04 UTC (rev 
14398)
+++ django/trunk/django/test/testcases.py   2010-10-30 13:03:37 UTC (rev 
14399)
@@ -305,9 +305,20 @@
 """ Performs any post-test things. This includes:
 
 * Putting back the original ROOT_URLCONF if it was changed.
+* Force closing the connection, so that the next test gets
+  a clean cursor.
 """
 self._fixture_teardown()
 self._urlconf_teardown()
+# Some DB cursors include SQL statements as part of cursor
+# creation. If you have a test that does rollback, the effect
+# of these statements is lost, which can effect the operation
+# of tests (e.g., losing a timezone setting causing objects to
+# be created with the wrong time).
+# To make sure this doesn't happen, get a clean connection at the
+# start of every test.
+for connection in connections.all():
+connection.close()
 
 def _fixture_teardown(self):
 pass
@@ -575,9 +586,6 @@
 transaction.rollback(using=db)
 transaction.leave_transaction_management(using=db)
 
-for connection in connections.all():
-connection.close()
-
 def _deferredSkip(condition, reason):
 def decorator(test_func):
 if not (isinstance(test_func, type) and issubclass(test_func, 
TestCase)):

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r14398 - in django/trunk: django/core/handlers django/test tests/regressiontests/middleware_exceptions

[noreply]

Author: russellm
Date: 2010-10-30 02:19:04 -0500 (Sat, 30 Oct 2010)
New Revision: 14398

Modified:
   django/trunk/django/core/handlers/base.py
   django/trunk/django/test/client.py
   django/trunk/tests/regressiontests/middleware_exceptions/tests.py
   django/trunk/tests/regressiontests/middleware_exceptions/urls.py
   django/trunk/tests/regressiontests/middleware_exceptions/views.py
Log:
Fixed #14588 -- Corrected r14393 to ensure that response middlewares are are 
always applied. Includes a battery of tests to validate the expected behavior 
of the middleware cycle. Thanks to Petr Marhoun for the report.

Modified: django/trunk/django/core/handlers/base.py
===
--- django/trunk/django/core/handlers/base.py   2010-10-30 04:28:43 UTC (rev 
14397)
+++ django/trunk/django/core/handlers/base.py   2010-10-30 07:19:04 UTC (rev 
14398)
@@ -78,40 +78,44 @@
 urlconf = settings.ROOT_URLCONF
 urlresolvers.set_urlconf(urlconf)
 resolver = urlresolvers.RegexURLResolver(r'^/', urlconf)
+response = None
 
 # Apply request middleware
 for middleware_method in self._request_middleware:
 response = middleware_method(request)
 if response:
-return response
+break
 
-if hasattr(request, "urlconf"):
-# Reset url resolver with a custom urlconf.
-urlconf = request.urlconf
-urlresolvers.set_urlconf(urlconf)
-resolver = urlresolvers.RegexURLResolver(r'^/', urlconf)
+if response is None:
+if hasattr(request, "urlconf"):
+# Reset url resolver with a custom urlconf.
+urlconf = request.urlconf
+urlresolvers.set_urlconf(urlconf)
+resolver = urlresolvers.RegexURLResolver(r'^/', 
urlconf)
 
-callback, callback_args, callback_kwargs = resolver.resolve(
-request.path_info)
+callback, callback_args, callback_kwargs = 
resolver.resolve(
+request.path_info)
 
-# Apply view middleware
-for middleware_method in self._view_middleware:
-response = middleware_method(request, callback, 
callback_args, callback_kwargs)
-if response:
-return response
-
-try:
-response = callback(request, *callback_args, 
**callback_kwargs)
-except Exception, e:
-# If the view raised an exception, run it through exception
-# middleware, and if the exception middleware returns a
-# response, use that. Otherwise, reraise the exception.
-for middleware_method in self._exception_middleware:
-response = middleware_method(request, e)
+# Apply view middleware
+for middleware_method in self._view_middleware:
+response = middleware_method(request, callback, 
callback_args, callback_kwargs)
 if response:
-return response
-raise
+break
 
+if response is None:
+try:
+response = callback(request, *callback_args, 
**callback_kwargs)
+except Exception, e:
+# If the view raised an exception, run it through 
exception
+# middleware, and if the exception middleware returns a
+# response, use that. Otherwise, reraise the exception.
+for middleware_method in self._exception_middleware:
+response = middleware_method(request, e)
+if response:
+break
+if response is None:
+raise
+
 # Complain if the view returned None (a common error).
 if response is None:
 try:
@@ -120,12 +124,6 @@
 view_name = callback.__class__.__name__ + '.__call__' 
# If it's a class
 raise ValueError("The view %s.%s didn't return an 
HttpResponse object." % (callback.__module__, view_name))
 
-# Apply response middleware
-for middleware_method in self._response_middleware:
-response = middleware_method(request, response)
-response = self.apply_response_fixes(request, response)
-
-return response
 except http.Http404, e:
 logger.warning('Not 

Re: [Django] #14588: Changed behaviour of middlewares after [14393]

[Django]

#14588: Changed behaviour of middlewares after [14393]
+---
  Reporter:  Petr Marhoun   | Owner:  
nobody
Status:  new| Milestone:

 Component:  Core framework |   Version:  
SVN   
Resolution: |  Keywords:

 Stage:  Accepted   | Has_patch:  0 

Needs_docs:  0  |   Needs_tests:  0 

Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * stage:  Unreviewed => Accepted

Comment:

 Yes, this is a change in behavior that wasn't picked up by our test suite.
 I've got a fix in progress, along with a bunch of tests to validate the
 intended behavior of the request/response cycle.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.