2011/4/4 Daniel Greenfeld <pyda...@gmail.com>:
> Anyway, as the current lead on Django Uni-Form I think its great that Gregor
> is picking up the torch for refactoring form rendering in Django 1.40. He's
> obviously done his homework and put a lot of thought into this critical part
> of Django.
> I'm not a core developer my vote doesn't count, but I'm giving it anyway. +1
> from me.
> Daniel Greenfeld
Hi Daniel, I really appreciate your support. It shows that I might be on the
right path for a successfull refactoring. Thanks.
@all:
I've updated my proposal. Mainly the media tag part and the timeline estimates
(nothing really exciting for the moment). A revision of the chrome section
will follow tomorrow. Have a look at the proposal online [1] or look below,
I've included the changed bits:
GSoC 2011 Proposal - Revised form rendering
============================================
...
Media aka. JS/CSS
-----------------
One of the other mainpoints in the discussions I reviewed for this proposal was
the use of JS and CSS files that must be maintained somehow to display them
how we already do through the media framework (e.g. ``{{ form.media }}``).
The problem with this is that with the new template tag we can change some
of the widgets in the template and introducing new dependencies. Thats why I
would like to have an alternative for the ``using`` argument in the
``{% form %}`` tag.
If ``using`` is replaced with ``configure``, the ``{% form %}`` tag will _not_
output the HTML in the current place. However it will record and remember the
usage of widgets and fields to determine which media files are required. An
example template would look like::
{% block extrahead %}
{% form myform configure widget "CalendarInput" for myform.birthday %}
^--- The new widget for the field birthday will be
recorded, but the form will not be rendered.
{{ myform.media.css }}
^--- Outputting all necessary css files.
{% endblock %}
{% block content %}
{% form myform %}
^--- The form will be rendered as usual but with the
"CalendarInput" widget that was specified in the other tag.
{% endblock %}
{% block footer %}
{{ myform.media.js }}
^--- Outputting all necessary js files at the end of the document.
{% endblock %}
I will also check the possibility and difficulty of a new ``{% formmedia %}``
tag that hooks into the template parsing system, reading until the end of the
template and analyzing the use of the ``{% form %}`` tag. This way it could
determine all changes that will be applied to the form before it gets
rendered, including all the necessary CSS dependencies that needs to be
imported in the header of the page.
It is not clarified yet, if the ``{% formmedia %}`` is possible at all with
the current template parsing implementation. There might be some risks that
need to be sorted out before starting with the implementation:
* By parsing from the ``{% formmedia %}`` tag until the end of the template
might result in that all content after this tag is represented as a child
node of it. What side effects are implied? Does it produce backwards
incompatibilities with thirdparty template tags?
* What happens if the ``{% form %}`` tag is changing the widget of the form
based on a context variable?
Estimates
---------
...
1st week: Starting to layout the documentation. The form tag syntax based on
discussions from the mailing list should already be finalized.
2nd week: Examing what unittests are available for the current form rendering
and making sure they are stable for testing backwards compatibility during the
project.
3rd week: I will attend DjangoCon EU, hopefully giving a talk about the
revised form rendering and collecting more feedback in an open space.
4th week: Converting the current layouts into template based renderers, ensuring
backwards compatibility.
Goal: no HTML should be left now in the python source.
5th week: Mainly working on documentation and integrating the very last changes
based on discussions from DjangoCon EU.
Goal: All public APIs should be stable.
6th week: Starting to write tests and implementing the ``{% form %}`` tag to
be able to emulate all the rendering that is currently possible.
7th week: Implementing the necessary rendering modifiers like "fields",
"layout" etc. and the API for chrome.
8th week: Implementing the ``{% formmedia %}`` tag.
Goal: Project should be feature complete.
9th - 11th week:
* Validating backwards compatibility for the ``{% formmedia %}`` parsing
implementation with thirdparty modules (see Media section).
* Converting the admin to use the new form rendering.
* Integrating lessons learned from the admin.
* Bugfixes and regression tests for problems that showed up in the work with
the admin.
Goal: Code should be ready to be used in sample projects.
12th week: Finalizing, bugfixes and tweaking the documentation.
...
Gregor
[1] https://gist.github.com/898375
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
