I think the current implementation means they affect all included children.
On 20 December 2016 at 07:15, Sjoerd Job Postmus wrote:
> On Mon, Dec 19, 2016 at 08:23:09AM +, Adam Johnson wrote:
> > >
> > > I guess the "safest" option is to keep the code around and let this
> > > feature die w
Daniel Wiesmann did all the work for RasterField. I'm not sure if he
follows this list but you can find his email address in the Django commit
longs and mail him to ask for his input.
https://github.com/yellowcap
On Tuesday, December 20, 2016 at 11:27:25 AM UTC-5, Piero Toffanin wrote:
>
> It's
It's stored on the file system. This is to improve performance when storing
large geospatial datasets.
This would only work on PostGIS.
On Thursday, December 15, 2016 at 3:11:37 PM UTC-5, Adam Johnson wrote:
>
> I can't say I'm that familiar with GeoDjango, but that does sound like a
> useful f
I think part of Sjoerd's point was that current implementation also means that
including the flag in a child affects parents -- but only with regard to said
child. So, if you have
url('a/', include("b"))
and in b:
url('b/$', blah),
url('c/$', bleh, flags=re.I),
then the valid urls include
a
This issue is actually limited to reverse(). When resolving urls, each
nested regex is matched against the url separately, so you can just apply
the flags to the "local" regex pattern, and get:
a/c/
a/C/
a/b/
matching, but not:
A/c/
A/C/
A/b/
The behaviour for reverse() can be a problem. For
Florian started a long discussion [0] on the pull request and concluded in
him saying, "If we are going to promote the usage of ProjectTemplateRenderer
(which I think we should), we probably should bite the dust and get rid of
POST_APP_DIRS and in the same breath of the jinja renderer -- ie prov
One option would be to introduce a new PREFIXES option in the template
engine settings which ignores template paths not starting with one of those
prefixes (if they are set). That said I didn't bother checking for
performance issues, I know that the cached loader in Django will also cache
if it
I think that a) wanting render forms via Jinja and everything else via
DTL, and b) caring about the perf impact of checking two engines is an
edge case, and a great reason to have the full flexibility of the form
renderers system. When we say "promote the usage of
ProjectTemplateRenderer", I think
I thought maybe that use case could be an argument for keeping the
Jinja2TemplateRenderer
-- we need it for testing the Jinja2 templates anyway, so it's not adding
any maintenance overhead, it's just a matter of whether it's public with
docs or if it just lives in the tests.
About the fate of
Sure, I guess Florian mentioned dropping Jinja2TemplateRenderer, but I
don't really see a strong argument against keeping and documenting it.
As you say, cost is low.
Carl
On 12/20/2016 11:55 AM, Tim Graham wrote:
> I thought maybe that use case could be an argument for keeping the
> Jinja2Templa
Okay I removed 'POST_APP_DIRS' from the PR.
Next, we should discuss whether or not to make the ProjectTemplate renderer
the default FORM_RENDERER in the startproject template. (For backwards
compatibility, DjangoTemplateRenderer has to be the default in
global_settings.py.)
Florian said:
On 12/20/2016 01:26 PM, Tim Graham wrote:
> Okay I removed 'POST_APP_DIRS' from the PR.
>
> Next, we should discuss whether or not to make the ProjectTemplate
> renderer the default FORM_RENDERER in the startproject template. (For
> backwards compatibility, DjangoTemplateRenderer has to be the def
I'm willing to cooperate on this one. Anyone is working on this and need help?
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
I've been intending to work on this for a while (as the original author of
WhiteNoise it would make the most sense for me to do the integration work)
but as ever the problem has been finding the time. I've been hoping to make
some progress on this over the Christmas period, but we'll see what ha
If you need some help, I'm as available as I can be.
Em ter, 20 de dez de 2016 19:50, David Evans escreveu:
> I've been intending to work on this for a while (as the original author of
> WhiteNoise it would make the most sense for me to do the integration work)
> but as ever the problem has been
I'll try to enhance the docs as you suggested.
I think it would be nice to be able to look at the name of the "project"
renderer and understand that it's connected to settings.TEMPLATES. I'm not
sure if the term "project" does that well. Maybe "TemplatesSettingEngines"?
On Tuesday, December 20,
On 12/20/2016 02:04 PM, Tim Graham wrote:
> I think it would be nice to be able to look at the name of the "project"
> renderer and understand that it's connected to settings.TEMPLATES. I'm
> not sure if the term "project" does that well. Maybe
> "TemplatesSettingEngines"?
Yeah... I guess I thoug
TemplatesSetting seems okay to me (open to other consensus though).
PR is updated: https://github.com/django/django/pull/6498
On Tuesday, December 20, 2016 at 5:19:32 PM UTC-5, Carl Meyer wrote:
>
>
> On 12/20/2016 02:04 PM, Tim Graham wrote:
> > I think it would be nice to be able to look at t
18 matches
Mail list logo
