[Django] #15667: Implement template-based widget rendering
Django
----------------------+---------------------------
Reporter: brutasse | Owner: brutasse
Status: new | Milestone: 1.4
Component: Forms | Version:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 |
----------------------+---------------------------
Following [https://groups.google.com/d/topic/django-
developers/fMQnk2fAo_A/discussion this proposal on django-dev], this
ticket tracks the status of replacing the widgets rendering code with a
template-based system.
The proposal is based on an existing implementation,
[https://github.com/brutasse/django-floppyforms django-floppyforms]. The
api provides several ways of extending a widget:
* Widget.template_name: the name of the template used to render the widget
* Widget.get_context_data(): a way to inject additional context data
* Widget.get_context(name, value, attrs=None): this method calls
get_context_data() and provides the basic context variables: attrs,
hidden, name, required, type.
I'm actively working on a patch and will attach it to the ticket as soon
as I can so that the implementation and extension points can be discussed.
--
Ticket URL: <http://code.djangoproject.com/ticket/15667>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Status: new | Milestone: 1.4
Component: Forms | Version:
Patch needs improvement: 0 |
--------------------------------------+------------------------
Changes (by carljm):
* cc: carl@… (added)
* needs_docs: => 0
* needs_tests: => 0
* needs_better_patch: => 0
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:1>
Django
Status: new | Milestone: 1.4
Component: Forms | Version:
Patch needs improvement: 0 |
--------------------------------------+------------------------
* cc: idan@… (added)
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:2>
Django
Status: new | Milestone: 1.4
Component: Forms | Version:
Patch needs improvement: 0 |
--------------------------------------+------------------------
* cc: jezdez (added)
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:3>
Django
Status: new | Milestone: 1.4
Component: Forms | Version:
Patch needs improvement: 0 |
--------------------------------------+------------------------
* cc: ironfroggy@… (added)
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:4>
Django
Status: new | Milestone: 1.4
Component: Forms | Version:
Patch needs improvement: 0 |
--------------------------------------+------------------------
* cc: poswald (added)
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:5>
Django
Status: new | Milestone: 1.4
Component: Forms | Version:
Triage Stage: Accepted | Has patch: 0
Patch needs improvement: 0 |
Changes (by julien):
* stage: Unreviewed => Accepted
Comment:
This would be a very welcome feature addition, provided that the
performance drawbacks would be kept to a minimum (as noted in the django-
dev thread).
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:6>
Django
Status: new | Milestone: 1.4
Component: Forms | Version:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 |
------------------------------------+------------------------
* cc: brutasse (added)
Comment:
Right, so I have a patch but it's too large for Trac :). I'll be using a
github branch instead:
https://github.com/brutasse/django/compare/15667-template-widgets
All the regressiontest changes are whitespace-related, or changes in the
widget attrs ordering (name="foo" value="bar" vs value="bar" name="foo").
A few comments on the curent implementation:
* !ClearableFileInput no longer has its 'template_with_initial' and
'template_with_clear' arguments. This breaks a widget in the admin but I
haven't started the admin widget migration yet. The question is whether
this is supposed to be a public API or not.
* The !RadioSelect "renderer" API should be deprecated. I left it
unchanged (although I added !PendingDeprecationWarnings), it still works
but it's not doing any template-based rendering. The templates give us
enough flexibility so I'm in favor of starting its deprecation.
* I added a template loader that is added to the list of loaders, this way
the templates are always available and they can be overridden in project-
or app-provided templates. Template caching works as expected, the cached
loader also caches the forms templates.
* I chose to explicitly add the input's "name" and "type" to the template
context instead of leaving it in the "attrs" dictionary. I like it this
way but I can put it back in the attrs if we decide to.
TODO:
* Topic documentation and widget reference (I'll make a draft but I
'''will''' need help here :)
* Convert the admin widgets
* Add tests for the new widgets API (make sure altering template_name,
get_context_data and get_context work as expected)
I'll keep reporting my progress here and will update my branch on github.
As always, comments welcome :)
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:7>
Django
Status: new | Milestone: 1.4
Component: Forms | Version:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 |
------------------------------------+------------------------
Comment (by carljm):
Replying to [comment:7 brutasse]:
> Right, so I have a patch but it's too large for Trac :). I'll be using a
github branch instead:
>
> https://github.com/brutasse/django/compare/15667-template-widgets
This looks great!
> * !ClearableFileInput no longer has its 'template_with_initial' and
'template_with_clear' arguments. This breaks a widget in the admin but I
haven't started the admin widget migration yet. The question is whether
this is supposed to be a public API or not.
They aren't arguments, just class attributes. And they are not documented
(I avoided documenting them specifically because I was hoping we could
soon get rid of them by moving to template-based widgets). It's probably
worth a note in the release notes in this patch for anyone who had a
subclass overriding them, but since they aren't documented I don't think
we need to provide the full deprecation path for them.
> * The !RadioSelect "renderer" API should be deprecated. I left it
unchanged (although I added !PendingDeprecationWarnings), it still works
but it's not doing any template-based rendering. The templates give us
enough flexibility so I'm in favor of starting its deprecation.
Agreed.
> * I added a template loader that is added to the list of loaders, this
way the templates are always available and they can be overridden in
project- or app-provided templates. Template caching works as expected,
the cached loader also caches the forms templates.
So I think this is the trickiest part here. I'm hesitant to introduce
another implicit coupling between conceptually-separate components of
Django, and it makes me cringe a bit that there's now no way to use the
Django template language without having this forms template loader added
automatically. That said, I don't have any other brilliant ideas for how
to make this "just work" transparently when people upgrade. Needs more
thought.
On a more minor note, I'm not a big fan of how you're finding the
forms_template_dir, relying on the relative filesystem location of
django/template/loaders/forms.py and django/forms. I think it might be
better to import the django.forms module and use its __file__ attribute?
> * I chose to explicitly add the input's "name" and "type" to the
template context instead of leaving it in the "attrs" dictionary. I like
it this way but I can put it back in the attrs if we decide to.
I prefer this as well; more explicit.
> * Topic documentation and widget reference (I'll make a draft but I
'''will''' need help here :)
I'm happy to help with this at some point.
> I'll keep reporting my progress here and will update my branch on
github. As always, comments welcome :)
Great work, thanks!
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:8>
Django
Status: new | Milestone: 1.4
Component: Forms | Version:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 |
------------------------------------+------------------------
* cc: trebor74hr@… (added)
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:9>
Django
Status: new | Milestone: 1.4
Component: Forms | Version:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 |
------------------------------------+------------------------
* cc: gregor@… (added)
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:10>
Django
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Milestone: 1.4 | Component: Forms
Version: | Severity: Normal
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 |
Changes (by JMagnusson):
* cc: JMagnusson (added)
* severity: => Normal
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:12>
Django
Reporter: brutasse | Owner: brutasse
Milestone: 1.4 | Component: Forms
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 |
---------------------------------------+------------------------
* cc: dmclain (added)
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:13>
Django
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Milestone: 1.4 | Component: Forms
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
---------------------------------------+--------------------------
Changes (by brutasse):
* easy: => 0
Comment:
Some progress since the last update. The changes can be seen here:
https://github.com/brutasse/django/compare/15667-template-widgets
Carl, I integrated your suggestion to use {{{django.forms.__file__}}} to
locate the forms templates. I have to agree the coupling between the
template system and the forms library may be an issue. Maybe this should
be discussed on django-dev but the GSoC proposal about form rendering is
going to make this coupling even stronger if it gets merged.
Almost all admin widgets have been converted. All tests now pass, I added
a test for the admin !RadioInput widget. Now for some discussion:
- the MultiWidget class has a format_output() method that joins the
outputs from all of its widgets. The base MultiWidget just does
"".join(outputs) but in the admin (see !AdminSplitDateTimeWidget) it
inserts some markup between the outputs. I'm not sure of the best way to
move this to the templates... Remove format_output and make MutiWidget use
a higher-level template? Leave it as it is and let the users decide if
they want format_output to use the template system or string
interpolation?
- Same for RelatedFieldWidgetWrapper. This basically wraps a widget, gets
its output and adds the "Add Another" link next to it. I'd be tempted to
make its render() method render the widget a separate template for the
"Add Another" button, then join the outputs. Not sure if there are better
options.
After these two points, the roadmap is to add tests for the extension
points (get_context_data, get_context, template_name) and document it as a
public API. Let me know if I overlooked something!
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:14>
Django
Reporter: brutasse | Owner: brutasse
Milestone: 1.4 | Component: Forms
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
---------------------------------------+--------------------------
Comment (by carljm):
Replying to [comment:14 brutasse]:
> I have to agree the coupling between the template system and the forms
library may be an issue. Maybe this should be discussed on django-dev but
the GSoC proposal about form rendering is going to make this coupling even
stronger if it gets merged.
I don't think it's acceptable to have this enforced two-way coupling
between forms and templates in the long run, but we do need to provide a
deprecation-smoothed upgrade path. Here's my proposal:
1. Add the form-defaults template loader to TEMPLATE_LOADERS in the
startproject template settings.py, but not to the global_settings
TEMPLATE_LOADERS default.
2. Document that you need to have the form-defaults template loader listed
in TEMPLATE_LOADERS, if you want to have any of Django's default
form/widget templates available (we should leave open the option that
someone wants to provide all the form/widget templates they will use
themselves, and not use any of the defaults built in to Django, though I
think this is pretty unlikely in practice).
3. Have temporary code that automatically adds the form template loader
(last in priority order) if it is not listed in TEMPLATE_LOADERS, like you
do now.
4. If the form template loader is not explicitly listed in
TEMPLATE_LOADERS and loads a template, have it issue
PendingDeprecationWarning. This would result in lots of warnings, which is
tricky. I don't want to make the warning module-wide, since, in the case I
mentioned above, if people don't need the form-defaults loader because
they provide all their own templates, they should be able to escape the
warning. So it should only warn if the form loader actually loads a
template. We might want to consider using some internal state on the
loader to make it a first-time-only warning? I don't really like that, but
it's better than hundreds of warnings or issuing the warning at module
scope, IMO.
5. When this deprecation cycle concludes in Django 1.6, remove the
automatically-add-form-template-loader code. At this point, if people
don't have the form template loader in TEMPLATE_LOADERS they'll just get a
TemplateNotFound error for any form template they need but don't provide
themselves.
I think this solution would be able to adapt to the increased use of
templates in Gregor's GSoC proposal without any trouble.
Does this sound like a reasonable approach? Anything I'm missing?
> - the MultiWidget class has a format_output() method that joins the
outputs from all of its widgets. The base MultiWidget just does
"".join(outputs) but in the admin (see !AdminSplitDateTimeWidget) it
inserts some markup between the outputs. I'm not sure of the best way to
move this to the templates... Remove format_output and make MutiWidget use
a higher-level template? Leave it as it is and let the users decide if
they want format_output to use the template system or string
interpolation?
I think we should leave format_output() in place for backwards
compatibility, and have its default implementation render a MultiWidget
template. Moving forward, format_output can become an internal
implementation detail, and overriding the template becomes the documented
way to customize MultiWidget rendering.
> - Same for RelatedFieldWidgetWrapper. This basically wraps a widget,
gets its output and adds the "Add Another" link next to it. I'd be tempted
to make its render() method render the widget a separate template for the
"Add Another" button, then join the outputs. Not sure if there are better
options.
I wouldn't implicitly join the outputs of two different templates; I'd
have a related-field-widget-wrapper template that takes the wrapped
widget's rendered HTML in its context and can wrap it however it wants.
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:15>
Django
Reporter: brutasse | Owner: brutasse
Milestone: 1.4 | Component: Forms
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
---------------------------------------+--------------------------
Comment (by brutasse):
Replying to [comment:15 carljm]:
I like that, I agree it's much better than 2-way coupling. I'll have a
look at the warnings and see how verbosity can be avoided.
> > - the MultiWidget class has a format_output() method that joins the
outputs from all of its widgets. The base MultiWidget just does
"".join(outputs) but in the admin (see !AdminSplitDateTimeWidget) it
inserts some markup between the outputs. I'm not sure of the best way to
move this to the templates... Remove format_output and make MutiWidget use
a higher-level template? Leave it as it is and let the users decide if
they want format_output to use the template system or string
interpolation?
>
> I think we should leave format_output() in place for backwards
compatibility, and have its default implementation render a MultiWidget
template. Moving forward, format_output can become an internal
implementation detail, and overriding the template becomes the documented
way to customize MultiWidget rendering.
So a MultiWidget gets a template attribute? (it currently doesn't have
any). By default it'd be {{{ {% for output in rendered_widget %}{{ output
}}{% endfor %} }}}. If it gets implemented like this I'd say
format_output() can be deprecated in favor of the API other widgets
already have (get_context(), etc), unless there is a use case for
format_output() that can't be implemented using a template. That'd be
mostly for consistency if we want a MultiWidget to have the same
customization hooks as every other widget.
> > - Same for RelatedFieldWidgetWrapper. This basically wraps a widget,
gets its output and adds the "Add Another" link next to it. I'd be tempted
to make its render() method render the widget a separate template for the
"Add Another" button, then join the outputs. Not sure if there are better
options.
>
> I wouldn't implicitly join the outputs of two different templates; I'd
have a related-field-widget-wrapper template that takes the wrapped
widget's rendered HTML in its context and can wrap it however it wants.
Ok, I'll do it this way. Thanks for your feedback :)
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:16>
Django
Reporter: brutasse | Owner: brutasse
Milestone: 1.4 | Component: Forms
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
---------------------------------------+--------------------------
* cc: mathieu.agopian@… (added)
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:17>
Django
Reporter: brutasse | Owner: brutasse
Milestone: 1.4 | Component: Forms
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
---------------------------------------+--------------------------
Comment (by carljm):
Replying to [comment:16 brutasse]:
> > > - the MultiWidget class has a format_output() method that joins the
outputs from all of its widgets. The base MultiWidget just does
"".join(outputs) but in the admin (see !AdminSplitDateTimeWidget) it
inserts some markup between the outputs. I'm not sure of the best way to
move this to the templates... Remove format_output and make MutiWidget use
a higher-level template? Leave it as it is and let the users decide if
they want format_output to use the template system or string
interpolation?
> >
> > I think we should leave format_output() in place for backwards
compatibility, and have its default implementation render a MultiWidget
template. Moving forward, format_output can become an internal
implementation detail, and overriding the template becomes the documented
way to customize MultiWidget rendering.
>
> So a MultiWidget gets a template attribute? (it currently doesn't have
any). By default it'd be {{{ {% for output in rendered_widget %}{{ output
}}{% endfor %} }}}.
Yes, I that seems to me like the most consistent and flexible option.
> If it gets implemented like this I'd say format_output() can be
deprecated in favor of the API other widgets already have (get_context(),
etc), unless there is a use case for format_output() that can't be
implemented using a template. That'd be mostly for consistency if we want
a MultiWidget to have the same customization hooks as every other widget.
Yes, I agree that format_output could probably start a deprecation path.
It's a little bit tricky - what you actually want to deprecate is a user-
defined subclass relying on format_output being called. I'd need to take a
closer look at the code to see the best way to do this.
I'm looking forward to getting this in; Gregor's GSoC on form rendering
will depend on some of this (particularly the form template loader), and I
don't want to hold up his progress (if necessary we can just apply this
patch in his branch -- I'd rather do that than apply this to trunk before
it's ready -- but it would simplify things if we just had this in trunk).
If you have a latest-state-of-the-patch with some tasks remaining to be
done, let me know and I'll see if I can help.
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:18>
Django
Reporter: brutasse | Owner: brutasse
Milestone: 1.4 | Component: Forms
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
---------------------------------------+--------------------------
Comment (by brutasse):
Ok, so according to the chat we had on IRC with Carl an Jannis,
format_output and renderer / get_renderer should be deprecated since it's
too hard to keep them along with the new API and they're not considered
public. This is done in the latest version of the patch:
https://github.com/brutasse/django/compare/15667-template-widgets
If a MultiWidget defines a format_output() method, calling render() raises
a DeprecationWarning and uses template-based rendering anyway. Same with
the renderers:
* providing renderer as a kwarg during RadioSelect instanciation raises
DeprecationWarning
* the RadioSelect class doesn't have a renderer attribute anymore
* any call to get_renderer() raises a DeprecationWarning and returns
RadioFieldRenderer
* RadioSelect's render() will **always** use templates
The admin's RelatedFieldWidgetWrapper now has its template attribute and
get_context method.
The template loader still needs to be worked on (Carl's comment 15 above).
I'll give it a go tomorrow night, CEST.
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:19>
Django
Reporter: brutasse | Owner: brutasse
Milestone: 1.4 | Component: Forms
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
---------------------------------------+--------------------------
Comment (by akaariai):
I did some performance testing using default settings of 1.3.0, except
that caching template loader was enabled.
I had two test, in the first one I had a a form with 11 integer fields.
using ipython %timeit, I got 1.76ms per loop with 1.3.0, and 3.72ms per
loop with code downloaded from GitHub. This seems good enough.
The second test is more worrisome. In this test I had 11
MultipleChoiceFields, each having 100 choices. The result without this
patch was 25ms per loop, with the patch 160ms per loop. With just 1 field
with 100 choices the results were 2.27ms vs 14.6ms. So, when using a 100
choice field the performance difference is 6.5x. Performance test code
attached.
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:20>
Django
Reporter: brutasse | Owner: brutasse
Milestone: 1.4 | Component: Forms
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
---------------------------------------+--------------------------
Comment (by akaariai):
Just to add some more info, I tried template based widgets with Jinja2
(version 2.1.1). I got very encouraging results, though it might be that I
am doing something wrong as the results seem to be too good to be true. I
got 1.47ms with Jinja2 vs 2.27 with Django 1.3.0. Most likely the speed
difference is because Jinja2 does not localize or escape some of the
values in the template, while the 1.3.0 implementation does. I haven't
looked more into this.
The conclusion that can be drawn from this example is that if template
compilation with comparable speeds to Jinja2 can be included in Django,
then this feature needs not be slower than current implementation at all.
For completeness, here are the steps needed to reproduce the jinja2
rendering test. I added the following code into widgets.py:
{{{
from jinja2 import Environment, PackageLoader
env = Environment(loader=PackageLoader('foobar', 'templates'))
def jinja_render_to_string(context):
template = env.get_template("select.html")
return template.render(**context)
}}}
and I added a directory foobar/templates/ to my testing root folder with
select.html in it (you need to change attrs.items to attrs.items() in the
first line of the template). Context is gotten by changing {{{ return
Context(context) }}} to {{{ return context }}} in Widget.get_context().
Then, Select.render() just calls jinja_render_to_string(context).
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:21>
Django
Reporter: brutasse | Owner: brutasse
Milestone: 1.4 | Component: Forms
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
---------------------------------------+--------------------------
Comment (by brutasse):
Replying to [comment:15 carljm]:
1) and 3) are done on the github branch, I'm not sure about the right way
to implement 4) while making it consistent across the cached and non-
cached template loaders... I'll dig a bit more but I'm open to
suggestions.
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:22>
Django
Reporter: brutasse | Owner: brutasse
Milestone: 1.4 | Component: Forms
Resolution: | Keywords:
Needs documentation: 1 | Needs tests: 0
---------------------------------------+--------------------------
* needs_docs: 0 => 1
* has_patch: 0 => 1
Comment:
I just pushed the code that warns if the forms template loader has been
automatically added:
https://github.com/brutasse/django/commit/b76dd323ce48e5e38061d59954990951653bfa0b
The missing bit is now documentation, unless there is something
fundamentally wrong with the patch.
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:23>
Django
Reporter: brutasse | Owner: brutasse
Milestone: 1.4 | Component: Forms
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 1
Needs documentation: 1 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
---------------------------------------+--------------------------
Comment (by carljm):
I'll try to find some time soon to review this in depth, write up some
docs, and see if there's anything we can do to bring some of the worst-
case performance numbers into better shape. Thanks for all the work on the
patch!
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:24>
Django
---------------------------------------+--------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Milestone: 1.4 | Component: Forms
Version: | Severity: Normal
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 1
Needs documentation: 1 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
---------------------------------------+--------------------------
Comment (by brutasse):
I generated some profiling graphs of the benchmarks here:
http://media.bruno.im/render_it.png
http://media.bruno.im/render_it2.png
I was wondering if the {% if %} check in the selectmultiple widget was a
bottleneck but looking at the graphs it doesn't look so. Not sure about
what can be done, the {% if %} check accounts for about 1% of the
rendering time. Most of the stuff going on is variable resolving and this
closed loop on the render_it2 graph, there is some circular stuff here
because of the {% for %} loop I guess.
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:25>
Django <https://code.djangoproject.com/>
Django
---------------------------------------+--------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Milestone: 1.4 | Component: Forms
Version: | Severity: Normal
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 1
Needs documentation: 1 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
---------------------------------------+--------------------------
Comment (by akaariai):
I have a feeling there is not much that can be done in this ticket to
improve the speed of MultipleChoiceField (or ChoiceField for that matter).
Current implementation of Django templates is just a bit slow. Maybe it
would be best to bring this up in django-developers for design decision?
Or mark this ticket design decision needed? As I see it, there are three
ways forward:
1. Accept the performance loss. For some users of 1.3 this can be a
decision which makes their current application unusable in 1.4.
2. Decide that the performance loss is unacceptable. In this case, this
ticket should wait for a faster implementation of Django template
rendering. Personally, I have high hopes that the GSOC project of Armin
Ronacher will achieve this.
3. Keep the default implementation of the performance-problematic widgets
in Python. One could still use template based rendering for these widgets,
but by default the python implementation would be used. This is a bit
uqly, but would allow this feature to get in without big worries of
performance problems for users upgrading to 1.4.
One small thing that could theoretically have an impact on performance is
the usage of context.update in get_context subclass methods. This is
creating a new stack entry in the context which can slow down variable
resolution. But as choices are in the upmost stack entry, this should not
have a big impact. Still, it would be IMHO cleaner if there would be just
one stack entry in the context given to the template.
--
Ticket URL: <http://code.djangoproject.com/ticket/15667#comment:26>
Django
Type: New feature | Status: new
Milestone: 1.4 | Component: Forms
Version: | Severity: Normal
Needs documentation: 1 | Needs tests: 0
UI/UX: 0 |
---------------------------------------+--------------------------------
Changes (by carljm):
* keywords: => form-rendering
* needs_better_patch: 0 => 1
* ui_ux: => 0
Comment:
Currently, the most up-to-date version of this patch lives in the 2011
GSoC form-rendering branch. The original GSoC branch is at
https://github.com/gregmuellegger/django/compare/master...soc2011%2Fform-
rendering and I've been making some further updates in
https://github.com/carljm/django/compare/master...soc2011%2Fform-rendering
That branch combines the templated widgets with a new form-rendering API.
The problem with the branch is still speed, and since it doesn't appear
we're going to get speed improvements in the template language in the
short term from Armin's GSoC, we need to look for other solutions. My
planned next step is to split back out just the templated-widgets from the
form-rendering branch in order to focus on seeing if we can improve that
to the point where we can commit it and close this ticket. Then we can
deal with the rest of the form-rendering API in a separate step.
There's also a bit of a framework for speed comparisons using djangobench
here: https://github.com/carljm/formrenderbench
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:27>
Django
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Comment (by carljm):
This patch would also fix #16630. Not closing that as duplicate because
it's more narrowly focused and can be done separately.
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:29>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
* cc: tom@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:30>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
* cc: tgecho (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:31>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
* cc: dguardiola@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:32>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
* cc: mmitar@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:33>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
* cc: philipe.rp@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:34>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by akaariai):
My opinion: if we want this, lets implement the default rendering in
Python. We could also provide default templates and compare output in
testing so that they produce the same result.
This isn't beautiful. But this way those who need absolute speed can get
it. In most of cases ultimate speed isn't a requirement.
Using template based forms does make so much sense that in my opinion the
code duplication is worth it.
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:35>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
* cc: Gwildor (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:36>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by Gwildor):
Are there any updates on this subject? In my humble opinion the widgets
are one of the ugliest parts of Django codewise and could logically learn
a lot from how the CBV's work. Most ''render()'' methods are a bit of a
mess, and this makes creating custom widgets which subclass an existing
widget, even subclassing something like ''Input'', one of the hardest
parts of the general things to do with the framework. Why has nothing
happened in the past two years?
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:37>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by chrismedrela):
See the lengthy discussion about introducing out-of-the-box support for
Jinja2 on django-developers: https://groups.google.com/forum/#!topic
/django-developers/Bk-22bKqCTo.
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:38>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by carljm):
Replying to [comment:35 akaariai]:
> My opinion: if we want this, lets implement the default rendering in
Python. We could also provide default templates and compare output in
testing so that they produce the same result.
>
> This isn't beautiful. But this way those who need absolute speed can get
it. In most of cases ultimate speed isn't a requirement.
>
> Using template based forms does make so much sense that in my opinion
the code duplication is worth it.
I agree that using template-based forms makes so much sense that it is
worth taking the performance hit by default, but I have a different
proposal for what those people should do who need "absolute speed" in
template rendering: use Jinja2 instead of DTL. Several adapters are
available that make Jinja2 work as a Django template loader (e.g.
[https://github.com/jbalogh/jingo jingo]), which means that it can be a
drop-in replacement for DTL (apart from needing to update template syntax,
of course). I think it's easy enough to switch to Jinja2 if you really
need the speed that it is not worth us maintaining two separate widget
rendering systems in Django.
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:39>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Component: Forms | Version:
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by aaugustin):
Master now provides first-class support for Jinja2, removing the main
objection to this ticket.
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:40>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
* version: => master
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:41>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by auvipy):
Replying to [comment:40 aaugustin]:
> Master now provides first-class support for Jinja2, removing the main
objection to this ticket.
Hi augustin are you proposing to convert the template or widget rendering
in jinja2? how will be that adopt to existing widgets? like admin?
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:42>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: brutasse
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by timgraham):
I haven't read through all the history of this ticket, but I guess it
might work something like this: by default, widgets are rendered with
Django templates. If you have jinja2 configured in `TEMPLATES`, then
widgets can be rendered with it. The main point is not to add jinja2 as a
requirement for Django.
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:43>
Django
--------------------------------+------------------------------------
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
* status: new => assigned
* owner: brutasse => auvipy
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:44>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner: auvipy
Type: New feature | Status: assigned
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by auvipy):
Replying to [comment:43 timgraham]:
> I haven't read through all the history of this ticket, but I guess it
might work something like this: by default, widgets are rendered with
Django templates. If you have jinja2 configured in `TEMPLATES`, then
widgets can be rendered with it. The main point is not to add jinja2 as a
requirement for Django.
That is what I'm thinking, as aymeric says masters has first class support
for jinja2 does that mean using jinja2 for form rendering and then modify
the contrib apps widgets with that? for standardizing django form
rendering what should be the move? stick with django or switching to
jinja2 permanently? or keeping to versions of different form rendering
system? 1 for backward compat and another for futureistic?
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:45>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner:
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
* owner: auvipy =>
* status: assigned => new
Comment:
Preston is [https://github.com/django/django/pull/4848 working on this].
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:46>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner:
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
* cc: cmawebsite@… (added)
Comment:
see also #16922
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:47>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner:
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
* cc: slav0nic@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:48>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner:
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by Tim Graham <timograham@…>):
In [changeset:"86573861a95e5a47dc7ff906443117d75b73dca1" 86573861]:
{{{
#!CommitTicketReference repository=""
revision="86573861a95e5a47dc7ff906443117d75b73dca1"
Refs #15667 -- Removed choices argument from some RendererMixin methods.
RendererMixin will soon be removed but this removal and the corresponding
test changes stand on their own.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:49>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner:
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
* needs_better_patch: 1 => 0
* needs_docs: 1 => 0
Comment:
A small issue detailed in the PR description remains, but otherwise I
think the [https://github.com/django/django/pull/6498 updated PR] is ready
for review.
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:50>
Django
Reporter: brutasse | Owner:
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* keywords: form-rendering => form-rendering 1.10
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:51>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner:
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Changes (by timgraham):
* keywords: form-rendering 1.10 => form-rendering
* needs_better_patch: 0 => 1
Comment:
We're a bit stuck on the backwards-compatibility issue, so deferring from
1.10.
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:52>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner:
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by GitHub <noreply@…>):
In [changeset:"26d0023cccd08473b0acc90e6f06bf3e93ebd847" 26d0023c]:
{{{
#!CommitTicketReference repository=""
revision="26d0023cccd08473b0acc90e6f06bf3e93ebd847"
Refs #15667 -- Fixed crash when indexing RadioFieldRenderer with
ModelChoiceIterator.
Regression in 86573861a95e5a47dc7ff906443117d75b73dca1
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:53>
Django
--------------------------------+------------------------------------
Reporter: brutasse | Owner:
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by Tim Graham <timograham@…>):
In [changeset:"1213ef2b182261ee690eba484ac7a929ff4707c9" 1213ef2b]:
{{{
#!CommitTicketReference repository=""
revision="1213ef2b182261ee690eba484ac7a929ff4707c9"
[1.10.x] Refs #15667 -- Fixed crash when indexing RadioFieldRenderer with
ModelChoiceIterator.
Regression in 86573861a95e5a47dc7ff906443117d75b73dca1
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:54>
Django
--------------------------------+------------------------------------
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Resolution:
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
* needs_better_patch: 1 => 0
Comment:
The [https://github.com/django/django/pull/6498 PR] is ready for review
again.
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:55>
Django
--------------------------------+------------------------------------
Reporter: Bruno Renié | Owner: (none)
Component: Forms | Version: master
Severity: Normal | Resolution: fixed
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Changes (by Tim Graham):
* status: new => closed
* resolution: => fixed
Comment:
In b52c73008a9d67e9ddbb841872dc15cdd3d6ee01:
Fixed #15667 -- Added template-based widget rendering.
Thanks Carl Meyer and Tim Graham for contributing to the patch.
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:56>
Django
--------------------------------+------------------------------------
Reporter: Bruno Renié | Owner: (none)
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: fixed
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by Tim Graham <timograham@…>):
In [changeset:"4e89082f31689d05a1b3aeaabd325f1b2cdcda5b" 4e89082f]:
{{{
#!CommitTicketReference repository=""
revision="4e89082f31689d05a1b3aeaabd325f1b2cdcda5b"
Refs #15667 -- Fixed form renderer test for Python 2 non-ASCII path.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:57>
Django
--------------------------------+------------------------------------
Reporter: Bruno Renié | Owner: (none)
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: fixed
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by Tim Graham <timograham@…>):
In [changeset:"12cefee5d84b3569ccbde03167c7853e8dac638f" 12cefee5]:
{{{
#!CommitTicketReference repository=""
revision="12cefee5d84b3569ccbde03167c7853e8dac638f"
Refs #15667 -- Prevented newlines in attrs.html widget rendering.
Removed the trailing newline from widget attrs.html template.
The solution may be revisited by fixing refs #9198 but not
for Django 1.11.
Thanks Dmitry Ivanchenko for the report and Preston Timmons for advice.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:58>
Django
--------------------------------+------------------------------------
Reporter: Bruno Renié | Owner: (none)
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: fixed
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by Tim Graham <timograham@…>):
In [changeset:"0a47b675b0280d2e60826773a0d08e83fdc7e44c" 0a47b67]:
{{{
#!CommitTicketReference repository=""
revision="0a47b675b0280d2e60826773a0d08e83fdc7e44c"
Refs #15667 -- Removed hardcoded icon size for related widget wrapper.
The template-based widget rendering branch was started years ago.
This is obsolete now.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:59>
Django
--------------------------------+------------------------------------
Reporter: Bruno Renié | Owner: (none)
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: fixed
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by GitHub <noreply@…>):
In [changeset:"0f46bc67e26d439517bb0d0cb474c72859e76b60" 0f46bc67]:
{{{
#!CommitTicketReference repository=""
revision="0f46bc67e26d439517bb0d0cb474c72859e76b60"
Fixed #27735 -- Doc'd form widget l10n change (refs #15667).
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:60>
Django
--------------------------------+------------------------------------
Reporter: Bruno Renié | Owner: (none)
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: fixed
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by Tim Graham <timograham@…>):
In [changeset:"f2b698631719c6df082a627b6f7ddf2d7f9fa751" f2b69863]:
{{{
#!CommitTicketReference repository=""
revision="f2b698631719c6df082a627b6f7ddf2d7f9fa751"
Fixed #28308 -- Doc'd removal of Select.render_option() (refs #15667).
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:61>
Django
--------------------------------+------------------------------------
Reporter: Bruno Renié | Owner: (none)
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: fixed
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by Tim Graham <timograham@…>):
In [changeset:"f20168e873d9c55b66aa49aee85d9e4804697afb" f20168e8]:
{{{
#!CommitTicketReference repository=""
revision="f20168e873d9c55b66aa49aee85d9e4804697afb"
[1.11.x] Fixed #28308 -- Doc'd removal of Select.render_option() (refs
#15667).
Backport of f2b698631719c6df082a627b6f7ddf2d7f9fa751 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:62>
Django
--------------------------------+------------------------------------
Reporter: Bruno Renié | Owner: (none)
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: fixed
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by Tim Graham <timograham@…>):
In [changeset:"2bd207ada0367debe8c8e298203435d5c88c14bd" 2bd207a]:
{{{
#!CommitTicketReference repository=""
revision="2bd207ada0367debe8c8e298203435d5c88c14bd"
Refs #15667 -- Removed support for Widget.render() methods without the
renderer argument.
Per deprecation timeline.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:63>
Django
--------------------------------+------------------------------------
Reporter: Bruno Renié | Owner: (none)
Type: New feature | Status: closed
Severity: Normal | Resolution: fixed
Keywords: form-rendering | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+------------------------------------
Comment (by GitHub <noreply@…>):
In [changeset:"6ad0dbc8d90ef37731608f7ac3d6e1d62cc8c765" 6ad0dbc8]:
{{{
#!CommitTicketReference repository=""
revision="6ad0dbc8d90ef37731608f7ac3d6e1d62cc8c765"
Refs #15667 -- Added resetting default renderer when FORM_RENDERER is
changed.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/15667#comment:64>