Re: Broken .dates() method?
Sorry, I've fallen asleep yesterday.
I "updated" Django to r14714 and it works fine. There are two
changesets after this one which are related to ORM, so I think the
problem is with them.
--
Valya Golev
On Sat, Nov 27, 2010 at 7:07 AM, Alex Gaynor wrote:
> On Fri, Nov 26, 2010 at 8:26 PM, Russell Keith-Magee
> wrote:
>> On Sat, Nov 27, 2010 at 9:23 AM, Russell Keith-Magee
>> wrote:
>>> On Sat, Nov 27, 2010 at 1:04 AM, Valentin Golev wrote:
Hello
One of my projects which is running on trunk version of Django (not in
production, of course) have been broken with recent updates.
DatabaseError at /news/ : near "FROM": syntax error
Django Version: 1.3 alpha 1 SVN-14719
/home/deploy/envs/fest/src/django/django/views/generic/dates.py in
get_date_list
date_list = queryset.dates(date_field, date_type)[::-1] ...
date_field 'date'
date_type 'day'
queryset [, ]
results in
params ('news', u'2010-11-01 00:00:00', u'2010-12-01 00:00:00',
u'2010-11-26 19:44:34.802072')
query 'SELECT DISTINCT FROM "news_uentry" WHERE
("news_uentry"."type" = ? AND "news_uentry"."date" >= ? AND
"news_uentry"."date" < ? AND "news_uentry"."date" <= ? ) ORDER BY 1
ASC'
DB engine is 'django.contrib.gis.db.backends.spatialite'
(You can see a full stacktrace on our test
server http://events.ride.ru/news/ )
I'll write a test and file a ticket; but maybe you've ran into this
bug already or I'm doing something wrong myself?
>>>
>>> I can't see anything obviously wrong with your syntax, and I can't say
>>> I've heard this report before. Looking at the stack trace, it looks
>>> like the column list has gone missing for some reason.
>>>
>>> Can you narrow this down to a single commit? e.g., 14717 works, but
>>> 14718 is broken? That will be very helpful in narrowing down the
>>> cause.
>>
>> ... and just as I press send, I discover ticket #14648.
>>
>> Yours,
>> Russ Magee %-)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>
> Bleh, Geo stuff :( Unfortunately I'm not equipped to test contrib.gis
> (and I thought I'd ripped out all the really invasive changes from my
> original diff).
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Strong security measures for the Auth Framework
On Sat, 2010-11-27 at 09:36 +0800, Russell Keith-Magee wrote: > So - if you can rephrase this in terms of a function/class API where > someone can define a mechanism for enforcing password strength, and > provide two implementations (the "any password is OK" policy and the > "cracklib policy" would be enough), then I can see this being a good > addition to Django. If I remember the auth forms code correctly, you can pass a custom form into all the views that handle passwords - new user, change password, password reset. The only inconvenience is that you they all call the password field different things, so you need to add a form with methods like 'clean_new_password' and 'clean_password' etc which would be essentially identical. So I would propose the introduction of some simple mixin like this: class DefaultPasswordPolicyMixin(object): def valid_password(self, password): return True All the auth forms should then be adapted to use this mixin and the valid_password method, and third parties can define their own mixin which overrides the method to create their own forms. Luke -- "Love is like an hourglass, with the heart filling up as the brain empties." Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Question on ImageField width_field/height_field motivations
Hi there - wondering why ImageField doesn't rely on width_field and height_field (if present and populated) for the dimensions? (i.e. from ImageField's perspective these seem to be "write-only" fields). This seems pretty unperformant (moving to ridiculously unperformant if you're using a remote storage like django-storages.s3). Or have I missed something in the code? -- Tim -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
ORM tests
I am working on adding support for another database to Django's ORM. Is there a certain set of tests in the Django package that test the ORM separately from other tests? Can anyone recommend a list of tests that I should ensure passing? Offhand, I would expect *all* tests run from 'manage.py test' to pass on a brand new app with only the database configured into settings.py. However, running that test suite gets many failures, and each is announced with a simple one-word error message line: 'ERROR' . This is not how other test-runners I have used announce failures. Thanks in advance. David -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ORM tests
On Sun, Nov 28, 2010 at 3:12 AM, dkeeney wrote: > > I am working on adding support for another database to Django's ORM. > > Is there a certain set of tests in the Django package that test the > ORM separately from other tests? Can anyone recommend a list of tests > that I should ensure passing? Well, to be completely certain, you need to run the full Django test suite [1]; but if you're just looking for a sanity check, the following subset: ./runtests.py --settings= aggregation basic expressions lookup many_to_many many_to_one model_inheritance one_to_one select_related queries will give you a good basic coverage of all the major features of the ORM. [1] http://docs.djangoproject.com/en/dev/internals/contributing/#running-the-unit-tests > Offhand, I would expect *all* tests run from 'manage.py test' to pass > on a brand new app with only the database configured into > settings.py. However, running that test suite gets many failures, and > each is announced with a simple one-word error message line: > 'ERROR' . This is not how other test-runners I have used announce > failures. I'm not sure what you're seeing here. I deliberately introduced an error into the test suite; this is what I get: (django)kronkite:tests rkm$ ./runtests.py --settings=sqlite basic Creating test database for alias 'default'... Creating test database for alias 'other'... ...sF.. == FAIL: test_object_creation (modeltests.basic.tests.ModelTest) -- Traceback (most recent call last): File "/Users/rkm/projects/django/hg/tests/modeltests/basic/tests.py", line 417, in test_object_creation ""]) File "/Users/rkm/projects/django/live/django/test/testcases.py", line 526, in assertQuerysetEqual return self.assertEqual(map(transform, qs), values) AssertionError: Lists differ: [' - ['', + ['', ?+ '', '', '', '', '', '', ''] -- Ran 11 tests in 0.081s FAILED (failures=1, skipped=1) Destroying test database for alias 'default'... Destroying test database for alias 'other'... You will sometimes get ERROR instead of FAIL on an individual test; this indicates that the test has failed in an unexpected way, rather than simply failing to pass an assertion. I can't think of any circumstance where you would *only* get the text ERROR on a line. Also - "manage.py test" only runs the tests for your specific project, not the full set of tests for Django itself. If you want to run the full Django test suite, you need to use runtests.py. The output of manage.py is the same as runtests.py; but the suite of tests executed by runtests is much larger. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Could the comments framework be more generic?
Hi, I'd like to make a suggestion about the build in comments framework. Right now, even though you can write your own extension to the comments framework, it is always tied to database models. I am trying to build an extension that uses the API offered by Disqus, meaning I don't want to use the local database to do a count of comments, get the list of comments, etc. If Django's comments framework would offer an API that is one level above the database models, we could write our own functions that implement getting comments, saving them, do a count of comments for the object, etc. I understand that a logical reaction to this suggestion would be to just not use Django's comments app, but roll my own. But I want to integrate the Disqus comments with existing apps, that already use Django's system to, for example, show the count of comments on blog articles in the admin interface. Django-blog-zinnia does this. I am looking forward to any comments and ideas. Is something like this even possible without completely breaking backwards compatibility? Kind regard, Kevin Renskers -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Pluggable encryption for django auth (design proposal)
Hi, all,
Right now, Django's auth system pretty much uses sha1 hardwired in (literally,
in the case of User.set_password) for the hash. For a discussion of why a
general-purpose hash function is not the best idea in the world for password
encryption, see:
http://codahale.com/how-to-safely-store-a-password/
I'd like to propose a backwards-compatible method of allowing different hash
algorithms to be used, while not adding new dependencies on external libraries
to the core.
1. Add a setting DEFAULT_PASSWORD_HASH. This contains the code for the
algorithm to use; if it is absent, 'sha1' is assumed.
2. Add a setting PASSWORD_HASH_FUNCTIONS. This is a map of algorithm codes to
callables; the callable has the same parameters as auth.models.get_hexdigest,
and return the hex digest its parameters (to allow for a single function to
handle multiple algorithms, the algorithm aprameter to get_hexdigest is
retained). For example:
PASSWORD_HASH_FUNCTIONS = { 'bcrypt':
'myproject.myapp.bcrypt_hex_digest' }
3. auth.models.get_hexdigest is modified such that if the algorithm isn't one
of the ones it knows about, it consults PASSWORD_HASH_FUNCTIONS and uses the
matching function, if present. If there's no match, it fails as it does
currently.
4. User.set_password() is modified to check the value of DEFAULT_PASSWORD_HASH,
and uses that algorithm if specified; otherwise, it uses 'sha1' as it does not.
(Optional: Adding the algorithm as a default parameter to User.set_password().)
Comments?
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Could the comments framework be more generic?
Hello All, Kevin's got a point, and actually, why aren't Django's components abstracted as a generic rule? Things like django.contrib.session and django.contrib.comments could be easily abstracted to allow for pluggable drivers into other backends quite easily. It'd be easy to make backward-compatible and would be VERY helpful. My best, Jamie On 27 November 2010 23:55, Kevin Renskers wrote: > Hi, > > I'd like to make a suggestion about the build in comments framework. > Right now, even though you can write your own extension to the > comments framework, it is always tied to database models. I am trying > to build an extension that uses the API offered by Disqus, meaning I > don't want to use the local database to do a count of comments, get > the list of comments, etc. > > If Django's comments framework would offer an API that is one level > above the database models, we could write our own functions that > implement getting comments, saving them, do a count of comments for > the object, etc. > > I understand that a logical reaction to this suggestion would be to > just not use Django's comments app, but roll my own. But I want to > integrate the Disqus comments with existing apps, that already use > Django's system to, for example, show the count of comments on blog > articles in the admin interface. Django-blog-zinnia does this. > > I am looking forward to any comments and ideas. Is something like this > even possible without completely breaking backwards compatibility? > > Kind regard, > Kevin Renskers > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Jamie Rumbelow developer/writer/speaker +44 (0)7956 363875 ja...@jamierumbelow.net -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Pluggable encryption for django auth (design proposal)
On Sat, Nov 27, 2010 at 10:14 PM, Christophe Pettus wrote: > Right now, Django's auth system pretty much uses sha1 hardwired in > (literally, in the case of User.set_password) for the hash. For a discussion > of why a general-purpose hash function is not the best idea in the world for > password encryption, see: > > http://codahale.com/how-to-safely-store-a-password/ Completely leaving aside the potential benefit of allowing different hash algorithms, I think the specific argument made by the author of that article, along with their proposed solution of an "intentionally slow" algorithm, is the wrong approach. Your application ends up just as hobbled by such an algorithm as a potential attacker. If you're choosing a slowdown factor based on your worst-case attacker, you're likely to significantly impair the ability of a website running on hardware that's not as fast, especially if you're authenticating users all the time. I think there are better potential solutions to concerns about password cracking. Django already salts the hashes, which is asymmetrical in a good way: it helps complicate brute force attacks without slowing down Django's ability to test a given password. Better password policies can also help; e.g., each additional letter you require in your users' passwords exponentially increases the space of passwords that need to be brute-forced. In cases where your attacker doesn't have direct access to the database, you can greatly slow them down by only allowing a certain amount of login attempts in a given time period. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Pluggable encryption for django auth (design proposal)
On Nov 27, 2010, at 8:05 PM, Tom X. Tobin wrote: > Your application ends up just > as hobbled by such an algorithm as a potential attacker. Actually, no, the situations are really quite asymmetrical. In order to brute-force a password, an attacker has to be able to try many, many thousands of combinations per second. To log in a user, an application has to do it exactly once. A hash computation time of, say, 10ms is probably unnoticeable in a login situation, unless you have tens of thousands of users logging in per minute (and if this is the case, then you probably have other problems than the speed of your password hash algorithm). But that would pretty much slam the door down on any brute force attempt at a password recovery. > Django already salts the hashes, which is > asymmetrical in a good way: it helps complicate brute force attacks > without slowing down Django's ability to test a given password. A salt is of no benefit on a brute force attack; it's function is to prevent dictionary attacks, which are a different animal. And if you are willing to assume that no attacker can ever get access to your database, then you don't have to hash the password at all. But, as you point out, that's a separate discussion from the value of pluggable encryption algorithms. There was a time that MD5 was the perfect answer; now, it's SHA-1. Different applications will have different needs as far as how they write the passwords to disk, and having an architecture to handle this seems like a good idea. -- -- Christophe Pettus x...@thebuild.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Could the comments framework be more generic?
On Sun, Nov 28, 2010 at 9:17 AM, Jamie Rumbelow wrote: > Hello All, > Kevin's got a point, and actually, why aren't Django's components abstracted > as a generic rule? Things like django.contrib.session and > django.contrib.comments could be easily abstracted to allow for pluggable > drivers into other backends quite easily. It'd be easy to make > backward-compatible and would be VERY helpful. Well, contrib.sessions is already pluggable -- that's what the SESSION_ENGINE setting is for. As for other contrib apps -- the reason is that either they're not inherently pluggable (e.g., webdesign), or that nobody has made the suggestion, or that nobody has done the work to make them pluggable. I'm generally in favor of anything that introduces a pluggable backend API that allows end-users to extend the functionality of Django's core. However, it's impossible to make any judgement in the absence of a specific API proposal. It's extremely easy to say "this can be done in a backwards compatible fashion". It's another thing entirely to put the effort into actually building a backwards-compatible patch. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Pluggable encryption for django auth (design proposal)
On Sat, Nov 27, 2010 at 11:47 PM, Christophe Pettus wrote: > Actually, no, the situations are really quite asymmetrical. In order to > brute-force a password, an attacker has to be able to try many, many > thousands of combinations per second. To log in a user, an application has > to do it exactly once. A hash computation time of, say, 10ms is probably > unnoticeable in a login situation, unless you have tens of thousands of users > logging in per minute (and if this is the case, then you probably have other > problems than the speed of your password hash algorithm). But that would > pretty much slam the door down on any brute force attempt at a password > recovery. But how far are you willing to go in your assumption of the worst-case computational ability of your attacker? Would tuning the hash to (say) a 10ms delay for your web server's modest hardware translate into a significant delay for an attacker with far more resources? (This isn't a rhetorical question; I honestly don't know.) > A salt is of no benefit on a brute force attack; it's function is to prevent > dictionary attacks, which are a different animal. It does in fact slow down brute force attacks against multiple encrypted passwords; each password with a different salt is within an entirely different space that needs to be brute forced separately from the other passwords. > And if you are willing to assume that no attacker can ever get access to your > database, then you don't have to hash the password at all. Sure, but my point was that there are various walls you can throw up against attackers to slow them down that don't involve slowing down your hash algorithm. > But, as you point out, that's a separate discussion from the value of > pluggable encryption algorithms. Right; I didn't mean to dissent from (or concur with) that proposal. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Pluggable encryption for django auth (design proposal)
On Nov 27, 2010, at 9:01 PM, Tom X. Tobin wrote:
> But how far are you willing to go in your assumption of the worst-case
> computational ability of your attacker? Would tuning the hash to
> (say) a 10ms delay for your web server's modest hardware translate
> into a significant delay for an attacker with far more resources?
> (This isn't a rhetorical question; I honestly don't know.)
Let's do the math. The space of eight alphanumeric character passwords is
2.8e12. Even assuming you can cut two orders of magnitude off of that with
good assumptions about the kind of passwords that people are picking, this
means that the attacker has to run about 28 billion times more computations
that you do. At 10ms per password, it would take them about 447.8 years to
crack a single password, assuming hardware of equivalent speed.
> It does in fact slow down brute force attacks against multiple
> encrypted passwords; each password with a different salt is within an
> entirely different space that needs to be brute forced separately from
> the other passwords.
Remember how a brute force attack works. Given a hash x, the attacker does:
hash('' + salt) = x? No, then,
hash('0001' + salt) = x? No, then,
...
The only benefit of the salt here is that it makes the string to be hashed a
bit longer, but the benefit is linear, not exponential.
A dictionary attack works by consulting a precomputed set of passwords and
their hashes, (pwd, hash(pwd)). The attacker then runs down the dictionary,
comparing hashes; if they get a hit, they know the password. The salt defeats
this by making the pwd -> hash(pwd) mapping incorrect.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Pluggable encryption for django auth (design proposal)
I wrote: > A dictionary attack works by consulting a precomputed set of passwords and > their hashes, (pwd, hash(pwd)). The attacker then runs down the dictionary, > comparing hashes; if they get a hit, they know the password. The salt > defeats this by making the pwd -> hash(pwd) mapping incorrect. I'm being slightly inaccurate here; what I'm describing above is a rainbow dictionary attack, rather than just a plain dictionary attack (which is a brute force attempt on the password over a limited range of input values). Anyway, a salt isn't helpful for a plain dictionary attack, either, for the same reason as a brute force attack. Anyway, back to the discussion of the actual proposal. :) -- -- Christophe Pettus x...@thebuild.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Pluggable encryption for django auth (design proposal)
On Sun, Nov 28, 2010 at 12:19 AM, Christophe Pettus wrote:
> Let's do the math. The space of eight alphanumeric character passwords is
> 2.8e12. Even assuming you can cut two orders of magnitude off of that with
> good assumptions about the kind of passwords that people are picking, this
> means that the attacker has to run about 28 billion times more computations
> that you do. At 10ms per password, it would take them about 447.8 years to
> crack a single password, assuming hardware of equivalent speed.
The point is that I'm *not* assuming hardware of equivalent speed.
I'm assuming that a worst-case attacker has hardware significantly
faster than your webserver at their disposal, so I was curious if the
purported benefit still held in that case. Maybe it does; I don't
know.
>> It does in fact slow down brute force attacks against multiple
>> encrypted passwords; each password with a different salt is within an
>> entirely different space that needs to be brute forced separately from
>> the other passwords.
>
> Remember how a brute force attack works. Given a hash x, the attacker does:
>
> hash('' + salt) = x? No, then,
> hash('0001' + salt) = x? No, then,
> ...
>
> The only benefit of the salt here is that it makes the string to be hashed a
> bit longer, but the benefit is linear, not exponential.
I'm not arguing that a salt helps against brute-forcing a *single*
password (it doesn't), but it does in fact help against someone trying
to brute-force your entire password database (or any subset of more
than one password), since each password with a different salt lies
within an entirely different space that must be brute-forced
separately from the rest.
> Anyway, back to the discussion of the actual proposal. :)
Sure, I didn't mean to veer things too far off course here; even
assuming the bcrypt argument doesn't hold, it's entirely possible that
someone may want to easily plug in SHA512/SHA3/whatever into their
password encryption.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
RFC: #12815/#12816 -- TemplateResponse and render() shortcut
Hi all, For your consideration, I present a patch to resolve #12815 and #12816, adding a TemplateResponse and a render() shortcut. Barring objection or feedback, my intention is to commit this patch mid week. This patch adds two features. Firstly, it adds a render() shortcut. This is just render_to_response(), but defaulting to using a RequestContext. Secondly, it adds a TemplateResponse class. This class is a 'lazy rendered' response -- you give it a request, template and context, and it defers rendering until late in the response process. The original idea for this feature was proposed by Simon Willison. The purpose is to allow decorators and middleware to modify a response after the view has finished with it. For example, you may have a middleware that modifies the template context, or changes the template depending on request-specific conditions -- for example, moving to using a different template if a mobile platform is detected. To do this, a TemplateResponse defers the rendering of a template until it is 'baked'. A TemplateResponse must be baked before response.content can be accessed; it is the baking process that combines the template and context into the final response content. Once baked, a TemplateResponse cannot be rebaked -- but you can manually set the response content. Attempts to access response.content before it is baked will raise an exception. This patch also introduces a new middleware layer -- the Template Response middleware. This middleware layer is invoked once the view has been invoked. When all template_response middlewares have been invoked, the response is baked, and the response middlewares are invoked. This patch also modifies the generic TemplateReponseMixin to use the new TemplateResponse class. This allows for the removal of several methods on the TemplateResponseMixin, as their functions are subsumed by the TemplateResponse itself. If you don't want to use a TemplateResponse, you can provide your own factory for responses; because render() has the same signature as the TemplateResponse constructor, you can use the render shortcut as a substitute. A big thanks to Mikhail Korobov and Ivan Sagalaev for their input in the design process, and especially to Mikhail for producing the draft patch. For those that followed the discussions and the original draft patches, some notable changes: - The render() shortcut doesn't use TemplateResponse. Since render() and TemplateReponse() have exactly the same prototype, I didn't see the value in adding a shortcut that just redirected to a different constructor. However, there is still value in making an easy-to-use render_to_response, for those situations where a TemplateResponse can't be used. - I've disabled repeat baking. My motivation for this is the fact that there is an automated baking step at the end of the template response middleware, so the effects of any calls to bake will be automatically overridden by Django's own stack. By disabling repeat baking, we can ensure that if the user actually requests baking, that baking sticks. Manual assignment of response.content can be used to overcome this -- response.bake() won't rebake content, but response.content = response.render() will force the new content to be applied. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
