I think for the moment, the easy fix for anonymous forms it either to put them on a different page or to load them with ajax.
This way the forms and thus the tokens gets generated only when needed. If caching and performances are a big concern, I think those alternative are win/win solutions. You solve your problem and remove load. My 2¢ On Oct 21, 2:39 pm, Carl Meyer <c...@oddbird.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/21/2011 07:02 AM, Jim Dalton wrote: > > > 1. Fixing #9249 and #15855. I hear your philosophical concerns about > > #9249 but the ubiquity of Google Analytics means we must do fine some > > way to fix it (IMO). Addressing these two tickets would at least > > ensure page caching wasn't actually broken. I'll try to jump in on > > those if I have time later next week. #9249 in particular seems quite > > close. > > > 2. Clarifying the documentation. I think an admonition in the page > > caching section of the docs which outlined the present challenges a > > developer might face implementing it would probably have done the > > trick for me when I was first glancing at it. I can open a ticket on > > that next week, again if I have time. > > > It'd be great if these two got in for 1.4. > > Agreed - any work you're able to put in on any of these is very welcome. > > > 3. Addressing the other stuff is I guess for now a sort of "some day" > > goal. I continue to feel strongly that it's a worthy goal, > > particularly given that CSRF and contrib.auth are such fundamental > > parts of most projects and that they really are the only two things > > that stand in the way of page caching being a viable option in many > > projects. If anyone else gets inspired by this goal let me know, > > otherwise I'm content for the time being to let it stew. > > I take your point that it might be possible to do a cache-tweaking API > that could allow the cache to be more aggressive around auth and CSRF > with less coupling (though you'd still end up sprinkling cache-specific > stuff into auth and CSRF with your approach). I remain pretty skeptical > about whether this is a good idea; it seems like it could significantly > increase the surface area for bugs in the cache middleware > implementation, and just generally make the implementation harder to > maintain with correct behavior. (I have some painful experience in this > area: CACHE_MIDDLEWARE_ANONYMOUS_ONLY is the one existing, and > relatively simple, instance of the type of enhanced caching logic you're > talking about, and I made some fixes to it in the 1.3 cycle that I then > later had to fix again due to unanticipated side effects of the first > change). But at this point this is all kind of hand-waving without code > to look at. > > You might also consider what's possible to do outside of core as a > third-party alternative to Django's caching middleware. When you're > proposing major and somewhat experimental changes, that can be a > powerful way to demonstrate that the idea is workable, and makes it a > lot easier to pick up users and advocates; people are generally more > willing to try out a third-party tool than to run or test with a patched > Django. > > Carl > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > iEYEARECAAYFAk6hvEkACgkQ8W4rlRKtE2edBACfdsW7IHoDKBrpwzwGGMx+ww5g > U+AAoLZLn1CA6c1644kzsnZRZ6xaW60B > =QBjT > -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
