Yes I know that you can access the Field instance but it wouldn't be
possible to do {{ field.field.city }} since a Field is not supposed to
have any data stored with it.
That exactly is the BoundField's job and the reason there is a
distinction between bound and unbound field.

An implementation of GPSBoundField.city could look something like this:

@property
def city(self):
    if self.value():
        return get_city_of_coordinate(self.value())


Field wouldn't have self.value() in this case.

If that's not clear still, I can elaborate on the TabularField example.

Am 13.08.2015 23:13, schrieb Tim Graham:
> 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
>     <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
>     
> <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
>     <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>
> 
>     >
>     
> <https://groups.google.com/d/msgid/django-developers/9541ed1f-5070-4753-a046-9cf745cb79f2%40googlegroups.com?utm_medium=email&utm_source=footer
>     
> <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
>     <https://groups.google.com/d/optout>.
> 
> -- 
> 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-developers+unsubscr...@googlegroups.com
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com
> <mailto: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
> <https://groups.google.com/d/msgid/django-developers/d3f74990-8b4e-433a-8442-97a678a96658%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/55CD1522.1020403%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: OpenPGP digital signature

  • A... 'Moritz Sichert' via Django developers (Contributions to Django itself)
    • ... Tim Graham
      • ... 'Moritz Sichert' via Django developers (Contributions to Django itself)
        • ... Tim Graham
          • ... Preston Timmons
            • ... 'Moritz Sichert' via Django developers (Contributions to Django itself)
              • ... Tim Graham
                • ... 'Moritz Sichert' via Django developers (Contributions to Django itself)
                • ... Preston Timmons
                • ... Tim Graham
                • ... 'Moritz Sichert' via Django developers (Contributions to Django itself)

Reply via email to