[GSoC form-rendering] Weekly Check-in

[Gregor Müllegger]

Hi,

I unfortunatelly missed the last weekly check-in. However during this time I
was already on my travel to Amsterdam for DjangoCon Europe. During this
Conference and mostly during the sprints have I spoken to some of the core
contributors to get their opinion about my current form rendering proposal in
person. Idan had some really fantastic ideas about how we can improve on what
Carl and I came up with. He is also a professional designer and really knew
what was bugging him with forms he is writing.

He is also volunteering in writing up a description on how this will look
like and sending it to this mailinglist. So stay tuned and look out for his
message!

I got also some small work done during the sprints in improving the test
suite. Peter van Kampen and I removed the last remaining doctest in django's
test suite. I also mocked the tests for URLField's with verify_exists=True.
They used to access the internet which made the tests fail if you are on a
plane (for example ;-)

So let's see how Idan's wrap up will look like. This will be open for
discussion at the time its posted. If there are no major concerns with it I
will start writing documentation for this approach at the end of next week.

I cannot response to any message in the next five days since I'm involved in a
trip for university and a paper I need to write.

Thanks again to the really well organized Djangocon and espescially the
sprints. It was a great place to get things done.

--
Servus,
Gregor Müllegger

[Mikhail Korobov]

Hi Gregor & others,

I've noticed the https://github.com/idangazit/formrendering and it reminds me the approach I'm using for all my django 1.3 projects:

{# forms/fields/as_dl.html #}

<dl> <dt> {{ field.label_tag }}} </dt> <dd> {{ field }}

{% include "forms/fields/errors.html" %} </dd> </dl>

and then:

<form action='' method='POST'> {% csrf_token %} {% include 'forms/fields/as_dl.html' with field=product_form.title %} {% include 'forms/fields/as_dl.html' with field=product_form.conditions %}

<input type='submit'> </form>

This can be used in a loop:

{# forms/my_as_ul.html #}

{% include "forms/non_field_errors.html" %} 

<ul>

{% for field in form %}

<li>{% include 'form/fields/as_dl.html' %}</li> {% endfor %}

</ul>

and then:

{% include 'forms/my_as_ul.html' with form=product_form %}

If individual field should be changed then django-widget-tweaks can be used:

{% load widget_tweaks %}

<form action='' method='POST'> {% csrf_token %} {% include 'fields/as_dl.html' with field=form.title|attr:"autofocus" %}

{% include 'fields/as_dl.html' with field=form.conditions|add_class:"foo"|attr:"type:search" %}

{% include 'forms/buttons/submit.html' with value="Save" %} </form>

This approach does not provide all the sugar from the Idan's and Gregor's proposals (namely, it forces developer to list all fields if one field is to be tweaked) but it is quite simple, introduces no new concepts and can be used in existing django 1.3 projects.

[Gregor Müllegger]

Hi Mikhail,

2011/6/22 Mikhail Korobov <kmi...@googlemail.com>:

Idan, me and all the other guys at the sprints were discussing exactly
something like this. We used the syntax from the current proposal because we
thought that matches the already existing includes as close as possible and
let's you utilize template inheritance, while still having the opportunity to
have some extra behaviour.

Look at the final result what Idan wrote down and is currently discussed in
another thread:
http://groups.google.com/group/django-developers/browse_thread/thread/3791152616fd95ae

--
Servus,
Gregor Müllegger

[Gregor Müllegger]

Hi,

we finally found (IMO) a really good API for the form rendering related
template tags. There is currently an ongoing discussion on the mailinglist
[1]. Jacob raised some concerns related to the performance impact that future
form rendering will have. I will make this a more important point in my
thoughts while going to implement the mechanisms.

I also documented my already made changes in my github branch, like the
assertHTMLEqual method and more. I've also changed assertTemplateUsed to work
as context manager, which I will need to check what templates are touched
during the form rendering. I'm currently working on the code that will
actually render the form in the end but not on the form tags themselves, since
their API is still under discussion.

I will look over the mailinglist thread tomorrow, trying to get to a
conclusion and will start then writing documentation for the form tags.

[1] http://groups.google.com/group/django-developers/browse_thread/thread/3791152616fd95ae

btw: I will use this thread for my following weekly updates to unclutter
the mailinglist timeline a bit.

--
Servus,
Gregor Müllegger

[Gregor Müllegger]

Hi,

I wrote mainly documentation in the last week for how to use the new form
rendering as well as references in the template tag listing. I've also
implemented the form, formrow and formfield tags, I thought we might want to
have something to play with sooner than later. The docs/tests etc can be found
in my github branch.

--
Servus,
Gregor Müllegger

[Chris Beaven]

Hi Gregor, I've just put up a new version of django-forms [1] which implements a similar version of the proposal with the main difference being "extends". Take a look.

1. https://github.com/SmileyChris/django-forms

[Gregor Müllegger]

Hi, Chris.

Seems that I'm now unemployed as GSoC Student,
looks like you already did all the work! ;-)

Besides this, great work. If I understand the source code right (haven't run
it yet), then it's already feature complete, isn't it?

I also like the idea of "extends", I will definitely bring this up to Carl's
attention. I don't know if it's in the core devs taste to change the meaning
of a {% block %} slightly in the context of a form tag.

I try to keep you posted.

2011/7/5 Chris Beaven <smile...@gmail.com>:

[Chris Beaven]

On Wednesday, July 6, 2011 2:30:12 AM UTC+12, Gregor Müllegger wrote:

Hi, Chris.

Seems that I'm now unemployed as GSoC Student,
looks like you already did all the work! ;-)

I prefer to show prototype code than just discussing things. It's more fun :)

 

Besides this, great work. If I understand the source code right (haven't run
it yet), then it's already feature complete, isn't it?

Thrown together in 1.5 days and not very tested, but yes, mostly feature complete.

I also like the idea of "extends", I will definitely bring this up to Carl's
attention. I don't know if it's in the core devs taste to change the meaning
of a {% block %} slightly in the context of a form tag.

I don't know if it's in the other core devs taste either. I just decided it'd do for my demo. I don't really mind it, but I can see the potential confusion - it's not part of the tag's child_nodelists as it stands so you wouldn't be able to override it - and it wouldn't make much sense anyway because it wouldn't be out of the ordinary to use the same block name multiple times in the same template (inside of form tags).

Here's something for you to chew on, related to my earlier thoughts on needing to change the widget definition for a field:

It's not enough to just use a 'hidden' field template, because we also need error messages related to that field to show up as non_field_errors. So how do you think we should do that? (I have some ideas, but I'll let you think about it first)

[Gregor Müllegger]

So I did most of the actual implementation work for the tags which were
proposed on the mailing list. Only some small bits are missing and some edge
cases needs to be tested. But I'm quite happy with the progress so far.

Next will be completing the documentation and going on to the second part of
the summer. I still need to decide with my mentor on what comes next. Taking
care of media rendering, dog-fooding the API in the admin etc...

--
Servus,
Gregor Müllegger

[Gregor Müllegger]

Unfortunately I was not very productive in the last week. The reason are the
three exams for this term that kept me busy. The second bad news is that I
will be on vacation for the next week.

So I will definitely need some serious sprinting after I'm back. The admin
will be mainly the target of that work. To dog-food the API, validating that
the API is flexible for all the usecases in the admin and to later benchmark
how the new rendering will influence the performance.

--
Servus,
Gregor Müllegger

[Gregor Müllegger]

So after the exams, vacation and a short illness have I completed a week of
productive work.

All the parts that were discussed in detail on the mailing list a while back
are implemented. The new rendering API is completely in place and well tested.
I've manly added more documentation in the last week on how to create custom
form layouts, the new template tags and the template based widgets.

Also work on the admin has started to dog-food the new form API, but this is
still far from finished yet. Add and change forms use the template based
rendering but that hasn't brought any real benefits yet. But it should be
possible to further refactor it to make some of the
django.contrib.admin.helpers.* classes superfluously.

I found some use cases that are not yet possible with the form rendering
template tags. The biggest issue is that it's not possible to exchange field
labels with translated text. Currently there is no way of storing a translated
string in the templates as variable, like {% trans "foo" as var %}

--
Servus,
Gregor Müllegger

[Idan Gazit]

W00t, poking through the source.

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com (mailto:django-d...@googlegroups.com).
> To unsubscribe from this group, send email to django-develop...@googlegroups.com (mailto:django-develop...@googlegroups.com).
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Jannis Leidel]

On 20.08.2011, at 15:59, Gregor Müllegger wrote:

> I found some use cases that are not yet possible with the form rendering
> template tags. The biggest issue is that it's not possible to exchange field
> labels with translated text. Currently there is no way of storing a translated
> string in the templates as variable, like {% trans "foo" as var %}

I just added this feature in changeset 16712 [1].

Jannis

1: https://code.djangoproject.com/changeset/16712

[Stephen Burrows]

> I found some use cases that are not yet possible with the form rendering
> template tags. The biggest issue is that it's not possible to exchange field
> labels with translated text. Currently there is no way of storing a translated
> string in the templates as variable, like {% trans "foo" as var %}

Can't you already do this with blocktrans? [1]

--Stephen

[1] https://docs.djangoproject.com/en/dev/topics/i18n/internationalization/#blocktrans-template-tag

[Jannis Leidel]

On 31.08.2011, at 18:15, Stephen Burrows wrote:

>> I found some use cases that are not yet possible with the form rendering
>> template tags. The biggest issue is that it's not possible to exchange field
>> labels with translated text. Currently there is no way of storing a translated
>> string in the templates as variable, like {% trans "foo" as var %}
>
> Can't you already do this with blocktrans? [1]

No, blocktrans prohibits using other template tags in its scope like the
template tag created during the GSoC because the makemessages management command
scans template files to update the PO files (it needs simple template variable,
e.g. `{{ my_var }}``).

Jannis