Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

t; > https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F6498%23issuecomment-268120711=D=1=AFQjCNH6pYlfIAgKUN59fcVGOTnZ7FikCw > > > < > https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F6498%23issuecomment-268120

Re: Template-based widget rendering

jango%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: > > >

Re: Template-based widget rendering

t; 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 > > <https://github.co

Re: Template-based widget rendering

Add 'POST_APP_DIRS' TEMPLATES option. > https://github.com/django/django/pull/7693 > <https://github.com/django/django/pull/7693> > Template based widget rendering: > https://github.com/django/django/pull/6498 > <https://github.com/django/django/

Re: Template-based widget rendering

> > 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/dja

Re: Template-based widget rendering

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 obje

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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': >

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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':

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

...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

Re: Template-based widget rendering

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 >

Re: Template-based widget rendering

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.

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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...

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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:

Re: Template-based widget rendering

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

Re: Template-based widget rendering

+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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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:

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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)

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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

Re: Template-based widget rendering

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 &

Template-based widget rendering

Hi all, 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 API to create configurable template loaders. Now

Re: Proposal: template-based widget rendering

Hi Bruno, On 03/23/2011 08:56 AM, Bruno Renié wrote: > I'm not sure, however, how django's backwards-compatibility applies in > this case. The widgets API has never been publicly documented but the > official documentation encourages people to look at the code and > create their own widgets based

Re: Proposal: template-based widget rendering

Hi Carl, On Tue, Mar 15, 2011 at 6:59 AM, Carl Meyer wrote: > > As we've already discussed here at PyCon, I'm +1 on this change. It > makes forms far more flexible and usable by template authors, and I > think that will benefit almost all Django users. It's more consistent >

Re: Proposal: template-based widget rendering

Hi Bruno, On 03/14/2011 06:33 PM, Bruno Renié wrote: > Although Django 1.3 is not released yet I'd like to take advantage of > the pycon sprints to discuss a proposal for 1.4: render form widgets > using Django templates instead of python code. > > This approach is implemented in

Proposal: template-based widget rendering

Hi django devs, Although Django 1.3 is not released yet I'd like to take advantage of the pycon sprints to discuss a proposal for 1.4: render form widgets using Django templates instead of python code. This approach is implemented in django-floppyforms [0] (I'm the author): each widget gets a