I replied to your comment on pr 5123 on github [1] but it seems to be
buried under "Show outdated diff" so here it is again:
I agree that as_text() and as_textarea() are not needed so I will remove
them from the docs.
There is a use case for as_widget() though. In one of my projects I have
a temp
While reviewing the proposed documentation for BoundField, I noticed the
methods BoundField.as_textarea() and as_text() [1] introduced at the start
of new forms [2]. According to the comment, their purpose is as "shortcuts
for changing the output widget type". These methods aren't documented, an
>
> 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.
>
This makes sense to me. Feel free to make a ticket and attach your PR once
it's ready for review.
Preston
--
Y
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
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
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 hav
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 c
I wonder if you have followed the ticket about template-based widget
rendering (it might be completed for 1.9).
https://code.djangoproject.com/ticket/15667
It looks to me like the functionality your branch enables might be better
as a custom widget, but I didn't study it too closely and could h
I split the commit in my branch to make the actual changes more visible
and moved the example out of the branch into the gist.
I will look into the ticket and work out some documentation.
Am 08.08.2015 um 13:42 schrieb Tim Graham:
> Here is a ticket for making BoundField a public API:
> https://c
Here is a ticket for making BoundField a public API:
https://code.djangoproject.com/ticket/12856
Writing that documentation seems like a good place to start.
I would suggest not to move around so much code in your branch as that
makes it difficult to tell what (if anything) has changed.
On Satu
Hello,
I'd like to propose a new feature for forms.
Currently if you need a form field with some extra features you can just
subclass from django.forms.Field and add all the features you need.
However as soon as you're in a template and want to access the field you
will get a BoundField instead
11 matches
Mail list logo
