Re: Template-based widget rendering

2016-12-20 Thread Tim Graham
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 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 thought ProjectTemplates got reasonably close to that, 
> since settings.TEMPLATES is the template configuration for your project. 
> I guess "TemplatesSettingEngines" could be OK, it just fails to roll off 
> the tongue. Not sure why we'd tack on "Engines" when we don't to any of 
> the other names (even though they all use a template engine or engines); 
> maybe just "django.forms.renderers.TemplatesSetting"? 
>
> I still slightly prefer "ProjectTemplates", but you're painting the 
> bikeshed, feel free to choose the color :-) 
>
> Carl 
>
>

-- 
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 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/959261a9-1533-4ff0-8cf7-36b9fe691b64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Template-based widget rendering

2016-12-20 Thread Carl Meyer

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 thought ProjectTemplates got reasonably close to that,
since settings.TEMPLATES is the template configuration for your project.
I guess "TemplatesSettingEngines" could be OK, it just fails to roll off
the tongue. Not sure why we'd tack on "Engines" when we don't to any of
the other names (even though they all use a template engine or engines);
maybe just "django.forms.renderers.TemplatesSetting"?

I still slightly prefer "ProjectTemplates", but you're painting the
bikeshed, feel free to choose the color :-)

Carl

-- 
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 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f7b131b4-910a-ec72-a045-badd4cba74ad%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: Template-based widget rendering

2016-12-20 Thread Tim Graham
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, 2016 at 4:35:45 PM UTC-5, Carl Meyer wrote:
>
> 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 default in 
> > global_settings.py.) 
> > 
> > Florian said: 
> > 
> >   the first question in IRC I (and everyone else in IRC) will have to 
> > answer for weeks will be: 
> > I have a nice context_processor where I specify the theme (color) of 
> > my material design template, why is the variable not in the templates 
> > for widgets, after all it is in the same template directory. 
> > I am already using django-sniplates via libraries in the TEMPLATE 
> > config, as migration step I want to reuse that for the widgets, why are 
> > they not getting picked up. 
> > 
> > Carl said: 
> > 
> > "the best we can do to address the support concern that may arise once 
> > people start to use custom widgets and wonder why their TEMPLATES config 
> > doesn't apply, is to clearly document that if you're creating custom 
> > widgets that need custom template features, you should upgrade to 
> > ProjectTemplateRenderer. (And we should update startproject to use 
> > ProjectTemplateRenderer, so this support concern is a temporary thing 
> > during the upgrade timeframe only.)" 
> > 
> > I feel these concerns may be overstated. I think custom template widget 
> > rendering won't be high on the list of things that Django beginners are 
> > looking to do and different values betwen "setting default" and 
> > "startproject default" causes confusion too. If we do make the addition, 
> > I guess 'django.forms' would be added  somewhere in INSTALLED_APPS also. 
>
> Yes, it would mean adding django.forms to INSTALLED_APPS as well. 
>
> Personally, I'm totally fine with deferring this decision until we see 
> how the default DTL renderer plays out in practice, and whether it does 
> cause confusion with people trying to build custom widgets. 
>
> I do think it'd be good to add to the DjangoTemplates renderer docs, 
> noting specifically that if you are using this renderer your custom 
> widget templates will use a "stock" DTL engine and won't have access to 
> any template engine customizations in your TEMPLATES setting, and 
> recommend ProjectTemplateRenderer if you need the latter. 
>
> > Finally, I'd like if the renderer names were less verbose. Proposal: 
> > django.forms.renderers.DjangoTemplates, Jinja2, TemplateEngines. 
>
> +1. The first two names are fine with me, not sure about 
> TemplateEngines. It seems kinda generic and unclear: all of the 
> renderers use "template engines" in one way or another. What about 
> "ProjectTemplates"? "ConfiguredTemplates"? 
>
> Carl 
>
>

-- 
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 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/71680f34-b22f-4812-8b82-bcf49489824d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: delegating our static file serving

2016-12-20 Thread Guilherme Leal
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 finding the time. I've been hoping to make
> some progress on this over the Christmas period, but we'll see what happens!
>
>
> On Tuesday, 20 December 2016 21:42:55 UTC, Guilherme Leal wrote:
>
> 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 to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9a6e143d-9bf9-4e26-89ca-cfc9944ba794%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAOs3Lp7qGjXiw7Ew7BPb%3D1h97gmOUMzorPJiEyjhXh2-uRTPCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: delegating our static file serving

2016-12-20 Thread David Evans
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 happens!

On Tuesday, 20 December 2016 21:42:55 UTC, Guilherme Leal wrote:
>
> 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 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9a6e143d-9bf9-4e26-89ca-cfc9944ba794%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: delegating our static file serving

2016-12-20 Thread Guilherme Leal
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 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fc0f3cd5-dbd6-4e04-844e-8f850be060a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Template-based widget rendering

2016-12-20 Thread Carl Meyer
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 default in
> global_settings.py.)
> 
> Florian said:
> 
>   the first question in IRC I (and everyone else in IRC) will have to
> answer for weeks will be:
> I have a nice context_processor where I specify the theme (color) of
> my material design template, why is the variable not in the templates
> for widgets, after all it is in the same template directory.
> I am already using django-sniplates via libraries in the TEMPLATE
> config, as migration step I want to reuse that for the widgets, why are
> they not getting picked up.
> 
> Carl said:
> 
> "the best we can do to address the support concern that may arise once
> people start to use custom widgets and wonder why their TEMPLATES config
> doesn't apply, is to clearly document that if you're creating custom
> widgets that need custom template features, you should upgrade to
> ProjectTemplateRenderer. (And we should update startproject to use
> ProjectTemplateRenderer, so this support concern is a temporary thing
> during the upgrade timeframe only.)"
> 
> I feel these concerns may be overstated. I think custom template widget
> rendering won't be high on the list of things that Django beginners are
> looking to do and different values betwen "setting default" and
> "startproject default" causes confusion too. If we do make the addition,
> I guess 'django.forms' would be added  somewhere in INSTALLED_APPS also.

Yes, it would mean adding django.forms to INSTALLED_APPS as well.

Personally, I'm totally fine with deferring this decision until we see
how the default DTL renderer plays out in practice, and whether it does
cause confusion with people trying to build custom widgets.

I do think it'd be good to add to the DjangoTemplates renderer docs,
noting specifically that if you are using this renderer your custom
widget templates will use a "stock" DTL engine and won't have access to
any template engine customizations in your TEMPLATES setting, and
recommend ProjectTemplateRenderer if you need the latter.

> Finally, I'd like if the renderer names were less verbose. Proposal:
> django.forms.renderers.DjangoTemplates, Jinja2, TemplateEngines.

+1. The first two names are fine with me, not sure about
TemplateEngines. It seems kinda generic and unclear: all of the
renderers use "template engines" in one way or another. What about
"ProjectTemplates"? "ConfiguredTemplates"?

Carl

-- 
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 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5d2bed65-88cf-5ab8-4f75-cdc61ef2b7b6%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: Template-based widget rendering

2016-12-20 Thread Tim Graham
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:

  the first question in IRC I (and everyone else in IRC) will have to 
answer for weeks will be:
I have a nice context_processor where I specify the theme (color) of my 
material design template, why is the variable not in the templates for 
widgets, after all it is in the same template directory.
I am already using django-sniplates via libraries in the TEMPLATE 
config, as migration step I want to reuse that for the widgets, why are 
they not getting picked up.

Carl said:

"the best we can do to address the support concern that may arise once 
people start to use custom widgets and wonder why their TEMPLATES config 
doesn't apply, is to clearly document that if you're creating custom 
widgets that need custom template features, you should upgrade to 
ProjectTemplateRenderer. (And we should update startproject to use 
ProjectTemplateRenderer, so this support concern is a temporary thing 
during the upgrade timeframe only.)"

I feel these concerns may be overstated. I think custom template widget 
rendering won't be high on the list of things that Django beginners are 
looking to do and different values betwen "setting default" and 
"startproject default" causes confusion too. If we do make the addition, I 
guess 'django.forms' would be added  somewhere in INSTALLED_APPS also.

Finally, I'd like if the renderer names were less verbose. Proposal: 
django.forms.renderers.DjangoTemplates, Jinja2, TemplateEngines.

On Tuesday, December 20, 2016 at 3:00:11 PM UTC-5, Carl Meyer wrote:
>
> 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 
> > 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 'POST_APP_DIRS' -- it seems the consensus among you 
> > and Florian is to drop it. Fine with me. 
> > 
> > On Tuesday, December 20, 2016 at 2:26:33 PM UTC-5, Carl Meyer wrote: 
> > 
> > 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 we mean as the most flexible and 
> > least 
> > surprising option for most projects that just want Things To Work, 
> not 
> > that it will always meet everyone's needs. If you have more specific 
> > needs, you can always write a form renderer that meets them. 
> > 
> > Carl 
> > 
> > On 12/20/2016 11:16 AM, Florian Apolloner wrote: 
> > > 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 doesn't find anything, ie it will not do extra I/O for 
> > > non-existing templates (after the initial round). As far as I 
> > understand 
> > > the Jinja2 code, non-existing file are extra I/O every time, so 
> that 
> > > might be something to consider. 
> > > 
> > > Cheers, 
> > > Florian 
> > > 
> > > On Tuesday, December 20, 2016 at 7:34:21 PM UTC+1, Tim Graham 
> wrote: 
> > > 
> > > 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 provide the Django renderer 
> > > really only as backwards compat shim." 
> > > 
> > > One concern I have is that if you want to 
> > > ues ProjectTemplateRenderer and render Jinja2 widget templates 
> > but 
> > > use Django templates elsewhere, then you have to put a Jinja2 
> > > backend first in TEMPLATES which means all your non-form 
> widget 
> > > template lookups have an additional cost of checking if the 
> > Jinja2 
> > > template exists. Does anyone have a 

Re: Template-based widget rendering

2016-12-20 Thread Carl Meyer
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
> 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 'POST_APP_DIRS' -- it seems the consensus among you
> and Florian is to drop it. Fine with me.
> 
> On Tuesday, December 20, 2016 at 2:26:33 PM UTC-5, Carl Meyer wrote:
> 
> 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 we mean as the most flexible and
> least
> surprising option for most projects that just want Things To Work, not
> that it will always meet everyone's needs. If you have more specific
> needs, you can always write a form renderer that meets them.
> 
> Carl
> 
> On 12/20/2016 11:16 AM, Florian Apolloner wrote:
> > 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 doesn't find anything, ie it will not do extra I/O for
> > non-existing templates (after the initial round). As far as I
> understand
> > the Jinja2 code, non-existing file are extra I/O every time, so that
> > might be something to consider.
> >
> > Cheers,
> > Florian
> >
> > On Tuesday, December 20, 2016 at 7:34:21 PM UTC+1, Tim Graham wrote:
> >
> > 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 provide the Django renderer
> > really only as backwards compat shim."
> >
> > One concern I have is that if you want to
> > ues ProjectTemplateRenderer and render Jinja2 widget templates
> but
> > use Django templates elsewhere, then you have to put a Jinja2
> > backend first in TEMPLATES which means all your non-form widget
> > template lookups have an additional cost of checking if the
> Jinja2
> > template exists. Does anyone have a sense if that would be a
> > noticeable performance penalty? (and perhaps an argument against
> > ProjectTemplateRenderer for a use case like that)
> >
> > [0]
> >
> https://github.com/django/django/pull/6498#issuecomment-268120711
> 
> >
> 
>  
> >
> 
> >
> > On Monday, December 19, 2016 at 5:53:23 PM UTC-5, Tim Graham
> wrote:
> >
> > It's ready for review:
> >
> > Add 'POST_APP_DIRS' TEMPLATES option.
> > https://github.com/django/django/pull/7693
> 
> >  >
> > Template based widget rendering:
> > https://github.com/django/django/pull/6498
> 
> >  >
> >
> > On Wednesday, December 14, 2016 at 6:59:16 PM UTC-5, Tim
> Graham
> > wrote:
> >
> > I don't have any strong objections at this point, just
> > wanted to think it through and offer possible
> alternatives.
> > If there's no further input, I'll finish adding tests and
> > docs for the TEMPLATES 'POST_APP_DIRS' option tomorrow,
> > after which I think the widget rendering patch will be
> ready
> > for final reviews.
> >
> > On Wednesday, December 14, 2016 at 6:40:36 PM UTC-5, 

Re: Template-based widget rendering

2016-12-20 Thread Tim Graham
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 'POST_APP_DIRS' -- it seems the consensus among you and 
Florian is to drop it. Fine with me.

On Tuesday, December 20, 2016 at 2:26:33 PM UTC-5, Carl Meyer wrote:
>
> 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 we mean as the most flexible and least 
> surprising option for most projects that just want Things To Work, not 
> that it will always meet everyone's needs. If you have more specific 
> needs, you can always write a form renderer that meets them. 
>
> Carl 
>
> On 12/20/2016 11:16 AM, Florian Apolloner wrote: 
> > 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 doesn't find anything, ie it will not do extra I/O for 
> > non-existing templates (after the initial round). As far as I understand 
> > the Jinja2 code, non-existing file are extra I/O every time, so that 
> > might be something to consider. 
> > 
> > Cheers, 
> > Florian 
> > 
> > On Tuesday, December 20, 2016 at 7:34:21 PM UTC+1, Tim Graham wrote: 
> > 
> > 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 provide the Django renderer 
> > really only as backwards compat shim." 
> > 
> > One concern I have is that if you want to 
> > ues ProjectTemplateRenderer and render Jinja2 widget templates but 
> > use Django templates elsewhere, then you have to put a Jinja2 
> > backend first in TEMPLATES which means all your non-form widget 
> > template lookups have an additional cost of checking if the Jinja2 
> > template exists. Does anyone have a sense if that would be a 
> > noticeable performance penalty? (and perhaps an argument against 
> > ProjectTemplateRenderer for a use case like that) 
> > 
> > [0] 
> > https://github.com/django/django/pull/6498#issuecomment-268120711 
> > <
> https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F6498%23issuecomment-268120711=D=1=AFQjCNH6pYlfIAgKUN59fcVGOTnZ7FikCw>
>  
>
> > 
> > On Monday, December 19, 2016 at 5:53:23 PM UTC-5, Tim Graham wrote: 
> > 
> > It's ready for review: 
> > 
> > Add 'POST_APP_DIRS' TEMPLATES option. 
> > https://github.com/django/django/pull/7693 
> >  
> > Template based widget rendering: 
> > https://github.com/django/django/pull/6498 
> >  
> > 
> > On Wednesday, December 14, 2016 at 6:59:16 PM UTC-5, Tim Graham 
> > wrote: 
> > 
> > I don't have any strong objections at this point, just 
> > wanted to think it through and offer possible alternatives. 
> > If there's no further input, I'll finish adding tests and 
> > docs for the TEMPLATES 'POST_APP_DIRS' option tomorrow, 
> > after which I think the widget rendering patch will be ready 
> > for final reviews. 
> > 
> > On Wednesday, December 14, 2016 at 6:40:36 PM UTC-5, Carl 
> > Meyer wrote: 
> > 
> > Hi Tim, 
> > 
> > On 12/14/2016 12:50 PM, Tim Graham wrote: 
> > > My thinking is that there should typically be only one 
> > directory in each 
> > > project that overrides built-in templates, otherwise 
> > if multiple apps 
> > > provide overrides, they'll stomp on each other when 
> > using the 
> > > app_directories loader.Are your projects usually set 
> > up that way? Using 
> > > the app_directories loader eases setup but adds a 
> > cognitive overhead of 
> > > figuring out where the template overrides are coming 
> > from. 
> > 
> > All of these seem like generic objections to APP_DIRS / 
> the 
> > app_directories loader, 

Re: Template-based widget rendering

2016-12-20 Thread Carl Meyer
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 we mean as the most flexible and least
surprising option for most projects that just want Things To Work, not
that it will always meet everyone's needs. If you have more specific
needs, you can always write a form renderer that meets them.

Carl

On 12/20/2016 11:16 AM, Florian Apolloner wrote:
> 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 doesn't find anything, ie it will not do extra I/O for
> non-existing templates (after the initial round). As far as I understand
> the Jinja2 code, non-existing file are extra I/O every time, so that
> might be something to consider.
> 
> Cheers,
> Florian
> 
> On Tuesday, December 20, 2016 at 7:34:21 PM UTC+1, Tim Graham wrote:
> 
> 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 provide the Django renderer
> really only as backwards compat shim."
> 
> One concern I have is that if you want to
> ues ProjectTemplateRenderer and render Jinja2 widget templates but
> use Django templates elsewhere, then you have to put a Jinja2
> backend first in TEMPLATES which means all your non-form widget
> template lookups have an additional cost of checking if the Jinja2
> template exists. Does anyone have a sense if that would be a
> noticeable performance penalty? (and perhaps an argument against
> ProjectTemplateRenderer for a use case like that)
> 
> [0]
> https://github.com/django/django/pull/6498#issuecomment-268120711
> 
> 
> 
> On Monday, December 19, 2016 at 5:53:23 PM UTC-5, Tim Graham wrote:
> 
> It's ready for review:
> 
> Add 'POST_APP_DIRS' TEMPLATES option.
> https://github.com/django/django/pull/7693
> 
> Template based widget rendering:
> https://github.com/django/django/pull/6498
> 
> 
> On Wednesday, December 14, 2016 at 6:59:16 PM UTC-5, Tim Graham
> wrote:
> 
> I don't have any strong objections at this point, just
> wanted to think it through and offer possible alternatives.
> If there's no further input, I'll finish adding tests and
> docs for the TEMPLATES 'POST_APP_DIRS' option tomorrow,
> after which I think the widget rendering patch will be ready
> for final reviews.
> 
> On Wednesday, December 14, 2016 at 6:40:36 PM UTC-5, Carl
> Meyer wrote:
> 
> Hi Tim,
> 
> On 12/14/2016 12:50 PM, Tim Graham wrote:
> > My thinking is that there should typically be only one
> directory in each
> > project that overrides built-in templates, otherwise
> if multiple apps
> > provide overrides, they'll stomp on each other when
> using the
> > app_directories loader.Are your projects usually set
> up that way? Using
> > the app_directories loader eases setup but adds a
> cognitive overhead of
> > figuring out where the template overrides are coming
> from.
> 
> All of these seem like generic objections to APP_DIRS / the
> app_directories loader, which has been around in some
> form (and been the
> default behavior) effectively forever. For better or
> worse, we have a
> template system that layers multiple loaders in the same
> template
> namespace and allows them to stomp on each other, and
> leaves it up to
> you to figure it out if they do. This does give people
> some rope to
> create confusion, but it's also powerful and flexible,
> and so far we've
> decided that tradeoff is worth it. How is any of this
> specific to form
> 

Re: Template-based widget rendering

2016-12-20 Thread Florian Apolloner
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 doesn't find anything, ie it will not do extra I/O for non-existing 
templates (after the initial round). As far as I understand the Jinja2 
code, non-existing file are extra I/O every time, so that might be 
something to consider.

Cheers,
Florian

On Tuesday, December 20, 2016 at 7:34:21 PM UTC+1, Tim Graham wrote:
>
> 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 provide the Django renderer really only as backwards 
> compat shim."
>
> One concern I have is that if you want to ues ProjectTemplateRenderer and 
> render Jinja2 widget templates but use Django templates elsewhere, then you 
> have to put a Jinja2 backend first in TEMPLATES which means all your 
> non-form widget template lookups have an additional cost of checking if the 
> Jinja2 template exists. Does anyone have a sense if that would be a 
> noticeable performance penalty? (and perhaps an argument against 
> ProjectTemplateRenderer for a use case like that)
>
> [0] https://github.com/django/django/pull/6498#issuecomment-268120711 
> 
>
> On Monday, December 19, 2016 at 5:53:23 PM UTC-5, Tim Graham wrote:
>>
>> It's ready for review:
>>
>> Add 'POST_APP_DIRS' TEMPLATES option. 
>> https://github.com/django/django/pull/7693
>> Template based widget rendering: 
>> https://github.com/django/django/pull/6498
>>
>> On Wednesday, December 14, 2016 at 6:59:16 PM UTC-5, Tim Graham wrote:
>>>
>>> I don't have any strong objections at this point, just wanted to think 
>>> it through and offer possible alternatives. If there's no further input, 
>>> I'll finish adding tests and docs for the TEMPLATES 'POST_APP_DIRS' option 
>>> tomorrow, after which I think the widget rendering patch will be ready for 
>>> final reviews.
>>>
>>> On Wednesday, December 14, 2016 at 6:40:36 PM UTC-5, Carl Meyer wrote:

 Hi Tim, 

 On 12/14/2016 12:50 PM, Tim Graham wrote: 
 > My thinking is that there should typically be only one directory in 
 each 
 > project that overrides built-in templates, otherwise if multiple apps 
 > provide overrides, they'll stomp on each other when using the 
 > app_directories loader.Are your projects usually set up that way? 
 Using 
 > the app_directories loader eases setup but adds a cognitive overhead 
 of 
 > figuring out where the template overrides are coming from. 

 All of these seem like generic objections to APP_DIRS / the 
 app_directories loader, which has been around in some form (and been 
 the 
 default behavior) effectively forever. For better or worse, we have a 
 template system that layers multiple loaders in the same template 
 namespace and allows them to stomp on each other, and leaves it up to 
 you to figure it out if they do. This does give people some rope to 
 create confusion, but it's also powerful and flexible, and so far we've 
 decided that tradeoff is worth it. How is any of this specific to form 
 templates? 

 > If you feel 
 > the ship has sailed and the pattern of putting the main "project" 
 module 
 > in INSTALLED_APPS to get "project-level"  templates rendered should 
 be 
 > endorsed, then I guess we'll do that. 

 I think some kind of "project" or "core" app is in practice pretty 
 common (e.g. it also becomes necessary if you want "project-level" 
 management commands, or DTL template tags, or...). I'm sure it's not 
 universal; I don't think there's anything wrong with it, or anything 
 wrong with not doing it. And I don't think that any decision we make 
 here needs to imply an endorsement of one approach or the other. 

 I understand that in my proposed default setup, if a project relies on 
 DIRS for their project-level templates, they won't be able to override 
 form templates along with the rest of their project-level templates; 
 they'll either need to switch to the ProjectTemplateRenderer or put 
 their form override templates in an app. That's not ideal, but I think 
 it's still a reasonable set of options (I'd probably go for 
 ProjectTemplateRenderer in that situation -- "if you want project 
 templates to override form templates, use ProjectTemplateRenderer" 
 seems 
 reasonable). While I agree 

Re: Considering removing support for ("iLmsu") regex groups in URLpatterns. Do you use them?

2016-12-20 Thread Marten Kenbeek
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 example, consider the 
following patterns:

url(r'([A-Z]+)/', include('b'))

and in b:

url(r'([A-Z]+)/$', blah, name='blah', flags=re.I)

Since the flag can only apply to the combined pattern r'([A-Z]+)/([A-Z]+)/$', 
we can either incorrectly reject reverse('blah', args=('A', 'b')), or we 
can return an invalid url for reverse('blah', args=('a', 'b')). 

This seems to be a problem with the current implementation as well, which 
would return an invalid url for reverse('blah', args=('a', 'b')), since 
(?i) applies to the whole pattern regardless of its position. 

re.I is probably the only flag we need to care about. re.U is always used, 
use of re.L is discouraged, and re.M/re.S only apply to multi-line strings. 

On Tuesday, December 20, 2016 at 5:50:39 PM UTC+1, Shai Berger wrote:
>
> 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/c/ 
> A/c/ 
> a/C/ 
> A/C/ 
> a/b/ 
>
> but not 
>
> A/b/ 
>
> which is a bit odd. 
>
> On Tuesday 20 December 2016 12:21:18 Adam Johnson wrote: 
> > 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 when the deprecation ends in Python 3.7 (and meanwhile 
> > > > > see 
> > > 
> > > if 
> > > 
> > > > > anyone notices the deprecation warning in their code and files a 
> > > > > ticket about it). The only extra work compared to removing this 
> now 
> > > > > is 
> > > 
> > > silencing 
> > > 
> > > > > the Python deprecation warnings in the Django tests in the 
> meantime. 
> > > > 
> > > > Sounds fair. Flags could always be added to *url()* as an extra 
> > > 
> > > parameter. 
> > > 
> > > How would that work with nested URL patterns? Would adding a flag also 
> > > apply that for the "parent" and/or "child" patterns? Would that also 
> > > work correctly for reverse? 
> > > 
> > > Asking because I seriously don't know. 
> > > 
> > > -- 
> > > 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 to django-develop...@googlegroups.com . 
> > > To post to this group, send email to django-d...@googlegroups.com 
> . 
> > > Visit this group at https://groups.google.com/group/django-developers. 
>
> > > To view this discussion on the web visit https://groups.google.com/d/ 
> > > msgid/django-developers/20161220071528.GA21882%40sjoerdjob.com. 
> > > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d567e297-2afd-405d-a139-aeb9f2375924%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Considering removing support for ("iLmsu") regex groups in URLpatterns. Do you use them?

2016-12-20 Thread Shai Berger
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/c/
A/c/
a/C/
A/C/
a/b/

but not

A/b/

which is a bit odd.

On Tuesday 20 December 2016 12:21:18 Adam Johnson wrote:
> 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 when the deprecation ends in Python 3.7 (and meanwhile
> > > > see
> > 
> > if
> > 
> > > > anyone notices the deprecation warning in their code and files a
> > > > ticket about it). The only extra work compared to removing this now
> > > > is
> > 
> > silencing
> > 
> > > > the Python deprecation warnings in the Django tests in the meantime.
> > > 
> > > Sounds fair. Flags could always be added to *url()* as an extra
> > 
> > parameter.
> > 
> > How would that work with nested URL patterns? Would adding a flag also
> > apply that for the "parent" and/or "child" patterns? Would that also
> > work correctly for reverse?
> > 
> > Asking because I seriously don't know.
> > 
> > --
> > 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 to django-developers+unsubscr...@googlegroups.com.
> > To post to this group, send email to django-developers@googlegroups.com.
> > Visit this group at https://groups.google.com/group/django-developers.
> > To view this discussion on the web visit https://groups.google.com/d/
> > msgid/django-developers/20161220071528.GA21882%40sjoerdjob.com.
> > For more options, visit https://groups.google.com/d/optout.


Re: GeoDjango OffdbRasterField

2016-12-20 Thread Piero Toffanin
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 feature. Where does the data get stored if not in the DB? And does 
> this feature exist on any of the other database backends that GeoDjango 
> supports?
>
> On 14 December 2016 at 18:40, Piero Toffanin  > wrote:
>
>> Hello,
>>
>> Not sure this is the right place to post this, if not, could somebody 
>> point me to the right place?
>>
>> I recently had the need to use GeoDjango to define a model that uses a 
>> RasterField to store a GeoTIFF raster. 
>> https://docs.djangoproject.com/en/1.10/ref/contrib/gis/model-api/#rasterfield
>>
>> Upon testing, one of the users of the application found that loading a 
>> large GeoTIFF (100Mb+) caused PostgreSQL to fail. More details about the 
>> report are available here: 
>> https://github.com/OpenDroneMap/WebODM/issues/55
>>
>> I went around the problem by using a relatively new feature of PostGIS 
>> that allows raster files to be stored off db. I noticed that RasterField 
>> does not support such feature, so I wrote the code to enable support for it 
>> via a new OffdbRasterField (
>> https://github.com/OpenDroneMap/WebODM/blob/master/app/postgis.py). 
>> The from_pgraster and to_pgraster functions are modified versions of the 
>> same functions found here: 
>> https://github.com/django/django/blob/master/django/contrib/gis/db/backends/postgis/pgraster.py
>>
>> Just wanted to see if there was an interest in adding off db raster 
>> support into GeoDjango core. Perhaps by modifying RasterField to have an 
>> additional parameter "offdb=True|False" and implement the necessary logic?
>>
>> Thanks,
>>
>> -Piero 
>>
>> -- 
>> 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 to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/cbcf7634-9b24-418a-9c16-9e9b7f77fa51%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Adam
>

-- 
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 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5b0ba3e3-733f-4304-bacf-dfc027d64806%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: GeoDjango OffdbRasterField

2016-12-20 Thread Tim Graham
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 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 feature. Where does the data get stored if not in the DB? And does 
>> this feature exist on any of the other database backends that GeoDjango 
>> supports?
>>
>> On 14 December 2016 at 18:40, Piero Toffanin  wrote:
>>
>>> Hello,
>>>
>>> Not sure this is the right place to post this, if not, could somebody 
>>> point me to the right place?
>>>
>>> I recently had the need to use GeoDjango to define a model that uses a 
>>> RasterField to store a GeoTIFF raster. 
>>> https://docs.djangoproject.com/en/1.10/ref/contrib/gis/model-api/#rasterfield
>>>
>>> Upon testing, one of the users of the application found that loading a 
>>> large GeoTIFF (100Mb+) caused PostgreSQL to fail. More details about the 
>>> report are available here: 
>>> https://github.com/OpenDroneMap/WebODM/issues/55
>>>
>>> I went around the problem by using a relatively new feature of PostGIS 
>>> that allows raster files to be stored off db. I noticed that RasterField 
>>> does not support such feature, so I wrote the code to enable support for it 
>>> via a new OffdbRasterField (
>>> https://github.com/OpenDroneMap/WebODM/blob/master/app/postgis.py). 
>>> The from_pgraster and to_pgraster functions are modified versions of the 
>>> same functions found here: 
>>> https://github.com/django/django/blob/master/django/contrib/gis/db/backends/postgis/pgraster.py
>>>
>>> Just wanted to see if there was an interest in adding off db raster 
>>> support into GeoDjango core. Perhaps by modifying RasterField to have an 
>>> additional parameter "offdb=True|False" and implement the necessary logic?
>>>
>>> Thanks,
>>>
>>> -Piero 
>>>
>>> -- 
>>> 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 to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/cbcf7634-9b24-418a-9c16-9e9b7f77fa51%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Adam
>>
>

-- 
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 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ff9c7349-fec4-4541-96bd-e7fca0fbbcd7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Considering removing support for ("iLmsu") regex groups in URLpatterns. Do you use them?

2016-12-20 Thread Adam Johnson
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 when the deprecation ends in Python 3.7 (and meanwhile see
> if
> > > anyone notices the deprecation warning in their code and files a ticket
> > > about it). The only extra work compared to removing this now is
> silencing
> > > the Python deprecation warnings in the Django tests in the meantime.
> >
> >
> > Sounds fair. Flags could always be added to *url()* as an extra
> parameter.
>
> How would that work with nested URL patterns? Would adding a flag also
> apply that for the "parent" and/or "child" patterns? Would that also
> work correctly for reverse?
>
> Asking because I seriously don't know.
>
> --
> 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 to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/20161220071528.GA21882%40sjoerdjob.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2EcX9uhZgmN4bqQ%3DY%3D%2Bk3zn98MsGO1WJWnfAX0x5NY9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.