I noticed that the GIS widgets didn't use the new API so I added a commit
for that. I tested the widgets in the geodjango tutorial and they looked
okay. I'm not sure how well those widgets are tested in Django's test suite
-- if any GIS users want to review the changes and/or test the branch wit
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
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
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 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
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:
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
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
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
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
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
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 thi
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
f
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 pro
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_directori
On 12/14/2016 11:08 AM, Carl Meyer wrote:
> As for whether a hypothetical third-party app that wants to override
> form widgets should do it by just providing the template overrides and
> clearly documenting that, or should do it by providing a custom form
> renderer, that's a separate question. I
On 12/14/2016 10:27 AM, Tim Graham wrote:
> I'm not sure if having the default renders insert the built-in form
> templates directory after the app dirs (as opposed to before, as usual
> with 'DIRS') is the best approach. On the PR, we discussed adding a new
> TEMPLATES 'POST_APP_DIRS' option to ac
I'm not sure if having the default renders insert the built-in form
templates directory after the app dirs (as opposed to before, as usual with
'DIRS') is the best approach. On the PR, we discussed adding a new
TEMPLATES 'POST_APP_DIRS' option to accomplish this but it might be
unneeded complex
Hi Tim,
On 12/07/2016 08:41 AM, Tim Graham wrote:
> This scheme seems to be working well so far.
Great, thanks for working on implementation. I did have intentions of
putting together the implementation once I'd gotten your feedback on the
design, but I won't complain if you've already done it :-
This scheme seems to be working well so far.
One thing you may not have thought of is that switching
to JinjaTemplateRenderer is incompatible with the admin because jinja2
templates aren't provided for those widgets. I think the reasoning was that
they're complicated to convert due to the use o
Carl,
The default renderer is backwards-compatible with no settings changes,
> and does not require Jinja2, but it still allows overrides/additions of
> widget templates. It's also standalone-compatible, in that it is
> self-contained and has no dependency on TEMPLATES config.
I like this id
Hi Tim,
On 11/16/2016 06:23 AM, Tim Graham wrote:
> I took a stab at backwards-compatibility with respect to allowing the
> admin to work without adding 'django.forms' to INSTALLED_APPS. It seems
> to work for at least the simple TEMPLATES = 'BACKEND':
> 'django.template.backends.django.DjangoTemp
I took a stab at backwards-compatibility with respect to allowing the admin
to work without adding 'django.forms' to INSTALLED_APPS. It seems to work
for at least the simple TEMPLATES = 'BACKEND':
'django.template.backends.django.DjangoTemplates', ...} case, although I'm
not proud of the code a
On 05/17/2016 01:33 AM, Claude Paroz wrote:
> I can imagine that django.forms would then be responsible to tell the
> template engine to add the template source. Maybe this would need a new
> API in the template code?
Yes, it's certainly possible that we could address this with a new API
in the te
Hi Simon,
On 05/17/2016 07:28 AM, charettes wrote:
> Did we consider defining a template loader that knows where to load the
> widget
> templates from instead of requiring 'django.forms' in INSTALLED_APPS with
> 'APP_DIRS': True in TEMPLATES?
>
> Something along theese lines make more sense to me
I'm not feeling particularly inspired about a solution for the
backwards-compatibility issue, and unless someone can work some magic today
in completing the patch, I think we'll defer this from 1.10.
On Tuesday, May 17, 2016 at 9:28:59 AM UTC-4, charettes wrote:
>
> Did we consider defining a te
Did we consider defining a template loader that knows where to load the
widget
templates from instead of requiring 'django.forms' in INSTALLED_APPS with
'APP_DIRS': True in TEMPLATES?
Something along theese lines make more sense to me:
TEMPLATES = {
{
'BACKEND': 'django.template.b
Le mardi 17 mai 2016 08:03:52 UTC+2, Carl Meyer a écrit :
>
> On 05/16/2016 01:48 AM, Claude Paroz wrote:
>
> > I'm still answering with my naive hat: isn't it possible to simply
> > always consider forms in django.forms without requiring anything new in
> > INSTALLED_APPS? What would be the p
On 05/16/2016 01:48 AM, Claude Paroz wrote:
> Le samedi 14 mai 2016 16:03:57 UTC+2, Tim Graham a écrit :
>
> (...)
>
> I guess it will affect every project that uses the admin. I can't
> think of a simple solution other than adding a system check upgrade
> warning to detect this s
Hi Tim,
On 05/14/2016 08:03 AM, Tim Graham wrote:
> While testing this, I ran into a shortcoming with the fallback strategy
> for backwards-compatibility.
>
> If you have a DjangoTemplates backend configured with 'APP_DIRS': True
> (as in the tutorial) and you try to visit /admin/auth/user/#/chan
Carl, there are other widgets such as
admin/widgets/related_widget_wrapper.html which include the built-in widget
templates. It's actually a variable include, {% include
widget.template_name %}, so copying the included template isn't feasible in
this case.
Claude, I'm not quite sure what the i
...always consider templates (not forms, sorry ) in django.forms ...
--
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 djang
Le samedi 14 mai 2016 16:03:57 UTC+2, Tim Graham a écrit :
>
> (...)
>
> I guess it will affect every project that uses the admin. I can't think
> of a simple solution other than adding a system check upgrade warning to
> detect this situation ('django.contrib.admin' in INSTALLED_APPS but not
>
On 16/05/16 15:10, Carl Meyer wrote:
On 05/15/2016 11:01 PM, Curtis Maloney wrote:
So this seems to leave us only part way to removing rendering decisions
from the form code -- your widgets can be templated, but your form code
still needs to decide which widgets...
Yep, one step at a time. Wi
On 05/15/2016 11:01 PM, Curtis Maloney wrote:
> So this seems to leave us only part way to removing rendering decisions
> from the form code -- your widgets can be templated, but your form code
> still needs to decide which widgets...
Yep, one step at a time. With django-floppyforms templated widg
On 12/05/16 01:04, Preston Timmons wrote:
Hey Curtis,
I think you're asking how this patch will help with form and field layouts?
If so, not that much. It only addresses moving the widget HTML that
currently is hardcoded in Python into templates.
No... was all to do with widget rendering...
C
On 05/15/2016 09:58 PM, Carl Meyer wrote:
> Yuck. Is there only one admin widget that includes a built-in widget? If
> so, I think we would maybe be better off just duplicating that one
> built-in widget in the admin templates.
That should read "built-in template," not "built-in widget."
Carl
--
While testing this, I ran into a shortcoming with the fallback strategy for
backwards-compatibility.
If you have a DjangoTemplates backend configured with 'APP_DIRS': True (as
in the tutorial) and you try to visit /admin/auth/user/#/change/ which
renders the ReadOnlyPasswordHashWidget, the tem
On 05/12/2016 09:39 AM, Tim Graham wrote:
> So this discussion doesn't stall the rest of the patch, I suggest
> keeping the fallbacks for now and deprecation them later if they cause
> confusion or other problems.
Yes, I think that makes sense.
Carl
--
You received this message because you are
So this discussion doesn't stall the rest of the patch, I suggest keeping
the fallbacks for now and deprecation them later if they cause confusion or
other problems.
On Wednesday, May 11, 2016 at 2:08:31 PM UTC-4, Carl Meyer wrote:
>
> On 05/11/2016 11:52 AM, Carl Meyer wrote:
> > On 05/11/2016
On 05/11/2016 11:52 AM, Carl Meyer wrote:
> On 05/11/2016 11:30 AM, Tim Graham wrote:
>> What's your proposal for changing the default TEMPLATES? Using Jinja2 or
>> DTL?
>
> At some point maybe we can adopt Jinja2 as a required dependency. Until
> then, the default startproject template can't use
On 05/11/2016 11:30 AM, Tim Graham wrote:
> I'm not sure about how common the need for custom widget templates are.
> Speaking for djangoproject.com and a few other small projects I
> maintain, I don't think these projects would make use of them but maybe
> if the feature is there, I might realize
I'm not sure about how common the need for custom widget templates are.
Speaking for djangoproject.com and a few other small projects I maintain, I
don't think these projects would make use of them but maybe if the feature
is there, I might realize it would help in some places.
What's your prop
Hey Curtis,
I think you're asking how this patch will help with form and field layouts?
If so, not that much. It only addresses moving the widget HTML that
currently is hardcoded in Python into templates.
For example, compare:
https://github.com/django/django/blob/master/django/forms/widgets.py#
Sorry for the late entry to the discussion, but I was looking over the
code and wondered about something.
In projects where I've used my django-sniplates for form rendering, it's
been helpful that I can have several different form widget sets within
the one project -- for instance, for side-by
+1. I like the simpler fallback solution Carl has suggested also.
Preston
--
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
Hi Tim,
On 05/10/2016 07:10 AM, Tim Graham wrote:
> About the fallback engines, the main use case I have in mind (as Claude
> alluded to) is if you want to use django.forms "standalone" without the
> rest of Django. In that case, it seems like it would be nice not to
> require someone to configure
About the fallback engines, the main use case I have in mind (as Claude
alluded to) is if you want to use django.forms "standalone" without the
rest of Django. In that case, it seems like it would be nice not to require
someone to configure settings.TEMPLATES. Here's an alternate proposal:
Crea
I agree with Carl’s arguments about the fallback strategy (specifically,
the four paragraphs quoted below).
--
Aymeric.
> On 10 May 2016, at 00:28, Carl Meyer wrote:
>
> Yeah... so relatedly, you also mentioned in IRC and on GH that you don't
> see why we should deprecate the automatic fallbac
Le mardi 10 mai 2016 00:28:57 UTC+2, Carl Meyer a écrit :
>
> I pushed an alternative approach in
>
> https://github.com/carljm/django/commit/7d734cfb9da2f64e4bf59c55167c70748b3bd092
>
> that removes the INSTALLED_APPS checking. Instead, it has the `render`
> method unconditionally fallback to
Hi Tim,
On 05/09/2016 08:03 AM, Tim Graham wrote:
> I've been working on testing and writing documentation for Preston's PR:
> https://github.com/django/django/pull/6498
>
> About backwards compatibility, the current implementation which seems to
> be based on Carl's proposal requires either a) '
I've been working on testing and writing documentation for Preston's PR:
https://github.com/django/django/pull/6498
About backwards compatibility, the current implementation which seems to be
based on Carl's proposal requires either a) 'django.forms' in
INSTALLED_APPS (so the APP_DIRS loader ca
Hi Carl,
Thanks for the feedback. I agree with your suggestions. I didn't think about
running a check for a combination of INSTALLED_APPS and a loader with
APP_DIRS. That would be sufficient for customizing loading.
I'll update and convert this to a PR.
Preston
--
You received this message bec
Hi Preston,
On 06/10/2015 11:46 AM, Preston Timmons wrote:
> I've been working through solutions for #15667 -- template based widget
> rendering. This is a problem that was close to a solution at one time, but
> stalled out due to performance concerns and difficulties with defining a
> workable AP
54 matches
Mail list logo
