I guess you know it's possible to access the regular form field with
BoundField.field, e.g. {{ field.field.city }} in {{ field.field.country }}.
Are there other advantageous to pushing those lookups to the BoundField as
opposed to the form Field besides the shorter access in the template? Maybe
you could motivate it with the TabularField example you mentioned.
On Thursday, August 13, 2015 at 3:42:46 PM UTC-4, Moritz S. wrote:
>
> My point isn't making accessing choices more easily, that's just the
> first thing I thought of for a simple example.
> Whether the current method for accessing the choices is good or not was
> not intended to be in the scope of my proposal.
>
> I want it to be possible to write more complex fields that have more
> properties than just their rendered html that also can't be represented
> with subwidgets.
>
> Take for example a "GPSCoordinatesField".
> It would be nice to do something like this in the template:
>
> {% if field.value %}
> The current value for the coordinates are:
> {{ field.city }} in {{ field.country }}
> {% endif %}
> Edit here:
> {{ field }}
>
> You could do this right now with custom template filters and do
> something like {{ field|get_gps_city }} but I think the former approach
> looks way better and it also makes sense to have the code for the city
> and country properties right in the BoundField instead of in a separate
> filter.
>
> It would also be possible to move the "The current value for ..." html
> inside a widget but here it really makes more sense having it in the
> template.
>
> Also my current real life use case I'd like to use this on is a
> "TabularField" that lets the user edit a table (adding and removing rows
> and editing individual cells) with the rows being defined by another
> form. This is not possible by using template filters or custom widgets.
>
> Am 13.08.2015 16:23, schrieb Preston Timmons:
> > Hi Moritz,
> >
> > Is the purpose of this patch to have a more convenient form of this:
> >
> > {% for choice in form.foo.field.choices %}
> > {{ choice.0 }} {{ choice.1 }}
> > {% endfor %}
> >
> > I'm not necessarily against the idea, but your patch seems to encourage
> > looping over the field choices rather than the widget choices. These two
> > values don't always match. A looping API should also account for the
> > case of nested choices, as well.
> >
> > Tim, #15667 makes it easier to loop through choices in the widget
> > template, but doesn't provide anything beyond the currently documented
> > API when accessing widget choices from the form instance:
> >
> > https://docs.djangoproject.com/en/1.8/ref/forms/widgets/#radioselect
> >
> > I'm happy to see improvement here if the current API is a pain point.
> > I'm not sure yet this is a better solution than the current API for
> > accessing widget choices.
> >
> > Preston
> >
> > --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "Django developers (Contributions to Django itself)"
> group.
> > To unsubscribe from this topic, visit
> >
> https://groups.google.com/d/topic/django-developers/-Bbi8vg5c9s/unsubscribe.
>
> > To unsubscribe from this group and all its topics, send an email to
> > django-develop...@googlegroups.com <javascript:>
> > <mailto:django-developers+unsubscr...@googlegroups.com <javascript:>>.
> > To post to this group, send email to django-d...@googlegroups.com
> <javascript:>
> > <mailto:django-d...@googlegroups.com <javascript:>>.
> > Visit this group at http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/django-developers/9541ed1f-5070-4753-a046-9cf745cb79f2%40googlegroups.com
>
> > <
> https://groups.google.com/d/msgid/django-developers/9541ed1f-5070-4753-a046-9cf745cb79f2%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
>
> > For more options, visit https://groups.google.com/d/optout.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/d3f74990-8b4e-433a-8442-97a678a96658%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
