Hello all,
This proposal is about adding value and display_value properties to
BoundFields (ticket #10427). The value property gives raw data and
display_value gives the value in user friendly format. For example for
CharField, both value and display_value will be just the raw data. But
for MultipleChoiceField, the value will be something like [1, 3, 14],
that is, not very usable to display to users directly. For
MultipleChoiceField The display_value will be the text representing
the choices.
I can think of at least two usage cases which are not easy to do at
the moment. The first is simply displaying the data of a model to
user. Using this feature you could achieve this by creating a
ModelForm with the instance's data and the following template:
{% for field in form.visible_fields %}
{{ field.label }}: {{field.display_value}}
{% endfor %}
The other usage case is a workflow which contains first a view page
for the form, with an edit link (Or edit -> preview -> save). This
would be achieved using the display_value in the preview stage.
As far as I know both of those usage cases are cubersome to do at the
moment, especially for ForeignKey and ManyToMany fields.
The current patch for #10427 implements value and display_value
properties for BoundField. The property values gives raw data using
the following rules:
1. If the form has data for this field, use it;
2. if the form has initial data for this field, use it;
3. if the field has initial data, use it; and lastly
4. use the empty string.
The display_value returns value, except for ChoiceField, which returns
the text of the choice.
The display_value property is clearly not sufficient, as it doesn't
handle MultipleChoiceField, formatting dates and it can't handle
custom fields and widgets properly. A good example of custom fields
and widgets that need special handling is django-ajax-selects:
http://code.google.com/p/django-ajax-selects/.
My proposal is to add display_value() method to widgets. That is, each
widget knows how to render it's value in user friendly format. For
most widgets this will just return the value. But some widgets need
special handling (DateInput, SelectMultiple, custom widgets...).
Now, a few questions:
1. Is this needed in core, is there some other functionality providing
this?
2. Is the proposed solution an acceptable way to do this?
3. What should the signature of widgets display_value be? At the
moment it is the same as render's, that is (name, value, attrs=()).
(Added with choices=() for widgets handling choices.)
4. How exactly should the display_value be rendered? One idea is to
always enclose the value in <div id="field_name">display_value</div>.
SelectMultiple would be rendered: <div
id="field_name"><ul><li>first_val</li><li>...</li></ul></div>.
5. Should it be possible to say to widget that it should use
display_value when rendering? This would be a replacement for
editable=False. In this case the rendering should probably include
hidden input so that when the form is submitted, the displayed value
can be retrieved from the submit.
In my mind leaving #5 for later is a good idea, so that the first
patch would be implementing only one thing. And there are numerous
other extensions to this feature one can think of...
I have a github repository containing a WIP patch for this (http://
github.com/akaariai/django/tree/ticket10427). At the moment it really
isn't ready, but the idea can be seen in code. Implemented tests are
still from the original #10427 patch, so they are not up to date at
the moment. I hope I will get some clarification to the questions, so
that I can implement this feature.
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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.
