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
signature.asc
Description: OpenPGP digital signature
