On Sun, Jan 11, 2015 at 11:33 AM, Collin Anderson
wrote:
> Hi All,
>
> Based on the early feedback, here's a scaled back proposal:
>
> 1. In the project_template settings.py for new projects:
> - Enable the request context processor
> - Keep the auth context processor
> - Remove the rest (you can
>From my experience some reusable apps require (in their documentation) that
specific context_processors are installed. I'm also -0 unless some decent
alternative exists and there's a convincing argument why they aren't a good
feature to have.
Cheers
On Sunday, 11 January 2015 14:33:44 UTC+11,
Hi All,
Based on the early feedback, here's a scaled back proposal:
1. In the project_template settings.py for new projects:
- Enable the request context processor
- Keep the auth context processor
- Remove the rest (you can always install them by hand).
2. Make the admin work without needing spe
On Sun, Jan 11, 2015 at 6:40 AM, Collin Anderson
wrote:
> Hi All,
>
> In talking to Aymeric and other developers, we're starting to think about
> the usefulness of global template context_processors. It seems to us that
> ideally you should only need the "request" context processor. You could
> e
I like it from a purity point of view, but I'm dreading updating through it
and replacing every instance of `{{ STATIC_URL }}` in my templates...
I also have a number of small projects which add a custom context processor
which add a certain queryset into the context every time because they form
a
Hello,
Here’s episode 14:
https://myks.org/en/multiple-template-engines-for-django/#2015-01-11
Hopefully I’ll reach the point where I don’t have enough material to write
a weekly update by the end of February :-)
--
Aymeric.
> On 4 janv. 2015, at 00:23, Aymeric Augustin
> wrote:
>
> Hello
Hi All,
In talking to Aymeric and other developers, we're starting to think about
the usefulness of global template context_processors. It seems to us that
ideally you should only need the "request" context processor. You could
even imagine removing context_processors all together and having re
For completeness, I'm Michael Manfre and have been the maintainer of
Django-mssql [1] for the last 6+ years. Future releases of Django-mssql
will officially support a single version of Django. Support for legacy
versions of Django will be maintained if it requires little effort.
Work on Django 1.8
Hi Tim!
At Potato we're developing Djangae: https://github.com/potatolondon/djangae,
which is a database backend for supporting Google App Engine datastore.
We're currently only supporting 1.6, but we're about to start development
of 1.7 support.
Thanks!
Ola
On Fri, Jan 9, 2015 at 5:00 PM, Tim G