Revised revised form rendering

[Mikhail Korobov]

Hi django developers,

GSoC'11 Gregor Müllegger's and Carl Meyer's project (Revised form rendering) seems to get stuck because of performance issues. 

Question 1. Am I understand this correctly and the limiting factor is the template rendering speed?

Question 2. Is it true that templates are not going to become faster anytime soon? I made this conslusion based on Armin Ronacher's GSoC'11 (Template Engine Compilation) results.

If answers for (1) and (2) are 'yes' then maybe we can explore non-template-based solutions that make form rendering easier to customize. Rendering simple <input> tag with dedicated django template is pure and clean approach but if it has critical performance penalty then I personaly totally ok with rendering 'input' tag in python if it is still customizable.

There is a working app ( https://bitbucket.org/kmike/django-widget-tweaks ) that can customize field rendering like this:

{% render_field form.text rows="20" cols="20" title="Hello, world!" class+="my_class1 my_class2" %}

or like this:

    {{ form.field|add_class:"my_class1 my_class2" }}

This is internally implemented by wrapping widgets' render method and adding to its 'attrs' argument.

This can be used with {% include %} tag to make field layout template-based (this is opt-in):

    {% include "inc/input.html" with field=form.field|add_class:"foo" %}

What django itself needs to make this app (or similar apps) work better is a public Widget and SubWidget API. It should be possible to iterate over subwidgets (e.g. select's options or checkboxes or radio buttons or parts of multi fields) in consistent way and subwidgets should expose the same interface as widgets. Field labels also should be widgets.

I haven't measured the speed of django-widget-tweaks vs template-based widgets vs existing django rendering, but it seems that even if the current implementation is slow (I don't know if it is slow or fast) with some core support it can be made fast.

By the way, there was a similar proposal several years ago: https://groups.google.com/d/topic/django-developers/XzaUuKGfuaE/discussion

 

Does all this stuff has a chance to go somewhere (of course if answers to questions (1) and (2) are 'yes') or template-based widget rendering is a true way and we should wait until computers become faster or django templates become faster or python become faster?

[Carl Meyer]

Hi Mikhail,

On 03/29/2012 01:31 PM, Mikhail Korobov wrote:
> GSoC'11 Gregor Müllegger's and Carl Meyer's project (Revised form
> rendering) seems to get stuck because of performance issues.
>
> Question 1. Am I understand this correctly and the limiting factor is
> the template rendering speed?
> Question 2. Is it true that templates are not going to become faster
> anytime soon? I made this conslusion based on Armin Ronacher's GSoC'11
> (Template Engine Compilation) results.

Yes, this is the situation.

> If answers for (1) and (2) are 'yes' then maybe we can explore
> non-template-based solutions that make form rendering easier to
> customize. Rendering simple <input> tag with dedicated django template
> is pure and clean approach but if it has critical performance penalty
> then I personaly totally ok with rendering 'input' tag in python if it
> is still customizable.
>
> There is a working app (
> https://bitbucket.org/kmike/django-widget-tweaks ) that can customize
> field rendering like this:

[snip]

> What django itself needs to make this app (or similar apps) work better
> is a public Widget and SubWidget API. It should be possible to iterate
> over subwidgets (e.g. select's options or checkboxes or radio buttons or
> parts of multi fields) in consistent way and subwidgets should expose
> the same interface as widgets. Field labels also should be widgets.

I'm certainly open to looking at patches to refactor the widget API for
better consistency; this proposal is still a bit vague to comment on
specifically. One issue I see immediatelyis that widgets play a dual
role: they are responsible both for rendering an HTML input element, and
they are responsible for extracting their data from incoming raw form
data and massaging it as necessary for a form field to handle.

It seems to me, based on your proposal that "sub-widgets" and field
labels should "be widgets", that you are focused entirely on the former
role, rather than the latter, since neither sub-widgets nor field labels
would have any role in extracting and parsing form data. Which makes me
think that if you go this route with a refactor you may want to
introduce a clearer conceptual separation between those two
roles/interfaces.

> I haven't measured the speed of django-widget-tweaks vs template-based
> widgets vs existing django rendering, but it seems that even if the
> current implementation is slow (I don't know if it is slow or fast) with
> some core support it can be made fast.
>
> By the way, there was a similar proposal several years
> ago: https://groups.google.com/d/topic/django-developers/XzaUuKGfuaE/discussion
>
> Does all this stuff has a chance to go somewhere (of course if answers
> to questions (1) and (2) are 'yes') or template-based widget rendering
> is a true way and we should wait until computers become faster or django
> templates become faster or python become faster?

I still hope that fully template-based form rendering can get into
Django in the future, though at this point I don't have a clear vision
of the path to get there. But I'm not interested in blocking
improvements in the existing system in the meantime.

Carl