I agree with Aymeric that the framework should contain any boilerplate
rather than force projects to implement it themselves.
On 9 February 2017 at 13:43, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello,
>
> I’m not a fan of having every project that needs case-insensitive f
Hello,
I’m not a fan of having every project that needs case-insensitive fields
declare:
class CICharField(CIText, CharField):
pass
class CITextField(CIText, TextField):
pass
class CIEmailField(CIText, EmailField):
pass
Could Django take care of providing these classes? (And perha
That looks good to me.
On Thursday, February 9, 2017 at 4:58:16 AM UTC-5, Mads Jensen wrote:
>
> I had the use case for shorter text strings in mind when I did the PR.
>
>
> https://github.com/atombrella/django/commit/ae8fe50f34329cbc969c5ac5bd368efd5b42b177
>
> <- would this be a better approac
I had the use case for shorter text strings in mind when I did the PR.
https://github.com/atombrella/django/commit/ae8fe50f34329cbc969c5ac5bd368efd5b42b177
<- would this be a better approach?
On Wednesday, February 8, 2017 at 6:09:26 PM UTC+1, Tim Graham wrote:
>
> I thought the mixin idea was
I thought the mixin idea was good but everyone else (including Aymeric)
reviewed the pull request and ignored your comment about that so I assumed
no one else saw its merits. Considering a CITextField that uses CharField
still has some usefulness as you mentioned, I'm in favor of CITextField not
> Does it make sense to add a CICharField for these cases or you can just
override the form/admin.
In a past Django developers discussion, Aymeric suggested building this
functionality with a mixin so the citext type could apply to multiple DB
fields which would then affect how the form field is r
Does it make sense to add a CICharField for these cases or you can just
override the form/admin.
On Wed, Feb 8, 2017 at 10:29 AM, Jon Dufresne
wrote:
> I believe this will also change the default form widget from type="text"> to . Is that also desired? IME, I most often use
> citext with short
I believe this will also change the default form widget from to . Is that also desired? IME, I most often use
citext with short text inputs, such as email.
On Wed, Feb 8, 2017 at 7:11 AM, Tim Graham wrote:
> Since that's a release blocker for a feature that hasn't been released
> yet, it's fine
Thanks Tim. I re-opened the ticket.
On Wed, Feb 8, 2017 at 9:11 AM, Tim Graham wrote:
> Since that's a release blocker for a feature that hasn't been released
> yet, it's fine to reference/reopen the original ticket rather than create a
> new one. I've created a PR, https://github.com/django/dja
Since that's a release blocker for a feature that hasn't been released yet,
it's fine to reference/reopen the original ticket rather than create a new
one. I've created a PR, https://github.com/django/django/pull/8034.
On Wednesday, February 8, 2017 at 7:40:02 AM UTC-5, Adam Johnson wrote:
>
> P
Pretty sure this is a new ticket since it's effectively a bug report
On 8 February 2017 at 11:00, Mads Jensen wrote:
>
>
> On Wednesday, February 8, 2017 at 11:32:22 AM UTC+1, Adam Johnson wrote:
>>
>> Sounds legit, make a ticket
>>
>
> Shouldn't https://code.djangoproject.com/ticket/26610 just
On Wednesday, February 8, 2017 at 12:00:23 PM UTC+1, Mads Jensen wrote:
>
> Shouldn't https://code.djangoproject.com/ticket/26610 just be reopened?
>
Nope, since that ticket indeed got fixed. A bug in something that got
committed usually also means new ticket.
--
You received this message bec
On Wednesday, February 8, 2017 at 11:32:22 AM UTC+1, Adam Johnson wrote:
>
> Sounds legit, make a ticket
>
Shouldn't https://code.djangoproject.com/ticket/26610 just be reopened?
> On 8 February 2017 at 00:37, Sean Brant >
> wrote:
>
>> I noticed the new postgres citext[1] field is a subclas
Sounds legit, make a ticket
On 8 February 2017 at 00:37, Sean Brant wrote:
> I noticed the new postgres citext[1] field is a subclass of CharField.
> Wouldn't it be more correct to subclass TextField? Subclassing CharField
> means we need to add a max_length which is ignored in the db.
>
> [1] h
I noticed the new postgres citext[1] field is a subclass of CharField.
Wouldn't it be more correct to subclass TextField? Subclassing CharField
means we need to add a max_length which is ignored in the db.
[1]
https://github.com/django/django/blob/master/django/contrib/postgres/fields/citext.py
15 matches
Mail list logo