> 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
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.
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 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
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
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
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 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
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
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
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
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
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
>
> 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
14 matches
Mail list logo
