>
> 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
On 13 août 2015, at 08:39, Loïc Bistuer wrote:
> How about we deprecate contrib.flatpages:
I think it’s sufficiently widely used and not sufficiently bad to make
deprecation a good tradeoff.
> - I see people abuse it all the time (do way more with it than they should)
> just because it's in c
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
It's a one line change in the code to keep the status quo from 1.8. The
main drawback I see is continued support tickets about dependencies between
apps with and without migrations. I already removed the documentation
describing the problem and "won't fixed" tickets that suggested doing more
to
On Tue, Aug 11, 2015 at 5:43 PM, Tim Graham wrote:
> It seems that django-contrib-comments has a moderation feature where you
> can specify a field on your model to control how comments are handled [2],
> so this was presumably used for that.
>
>
The field on FlatPage has been there since the beg
I've drafted a blog post to advertise our need for Oracle expertise. Please
take a look and give feedback before it's published. Thanks!
Django team seeks help maintaining Oracle and Oracle GIS backends
---
Sever
On 08/13/2015 12:39 AM, Loïc Bistuer wrote:
> How about we deprecate contrib.flatpages:
I'm not sure I agree with this. I think flatpages is actually an example
of the kind of thing that belongs in contrib: a simple app to fulfill a
simple, frequent need.
> - I see people abuse it all the time (d
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
The problem with bootstrapping code like this is that it's great for a
super simple project, but you instantly want to customise it for any
project of any serious scope.
It seems to me a perfect candidate for a simple external project, although
you may wish to have a different API so it's more reu
I asked this question on the user group and got no reply fast, so I just
wrote a derived class to do it quickly:
https://groups.google.com/d/msg/django-users/n87bFh8IYYc/MhkNmVBDAwAJ
it's a hack and not what I'd call a patch, but one user liked it and asked
that I seek it's inclusion in Django.
> On 13 Aug 2015, at 08:39, Loïc Bistuer wrote:
>
> How about we deprecate contrib.flatpages:
>
> - I see people abuse it all the time (do way more with it than they should)
> just because it's in core.
>
> - FlatpageFallbackMiddleware is hardly an example to follow.
>
> - It can easily live
14 matches
Mail list logo