Russell, my reply there isn't meant to be confrontational and yet
re-reading it I can see it being easily interpreted as such. My intention
is to ask whether there is something about swappable that I am missing. It
seems to work the way I stated above but your statement seems to imply that
th
>
> However, if auth.User (or any other model for that matter) is set as
> AUTH_USER_MODEL, nothing prevents EmailUser from being installed.
>
The current behavior of swappable is that if two models are swappable on
the same settings value, only the one designated by the settings value will
be
>
> I'm not sure it was the intention in the design of swappable.
I don't know the intended use of swappable, but this seems like exactly the
type of thing that a 'swappable' model should be able to do.
> However, we still have the issue of different forms, urls, views etc all
> based off t
I and my colleague (gavinw...@gmail.com) have made some edits to the wiki
to clarify the purpose of authtools, and more accurately explain what the
'authtools' approach would look like. If you previously have examined
'option 2', I would ask that you go and reread that section in the wiki.
htt
as the ability to turn off certain
models could introduce situations in which someone turns off a model
without replacing it.
Aaron Merriam
On Wednesday, September 18, 2013 1:39:16 PM UTC-6, Luke Sneeringer wrote:
>
> I added the authtools approach to the wiki for completion, although I
Russel, I'm curious if you could expand/explain your motivation on having
this implemented as a separate contrib application rather than including it
with django.contrib.auth
On Thursday, September 12, 2013 5:41:29 PM UTC-6, Russell Keith-Magee wrote:
>
>
> On Fri, Sep 13, 2013 at 4:44 AM, Abdul
ews, emailuser doesn't.
>>>
>>> 5. they have different licences, but I don't know enough about them to
>>> know what are the differences.
>>>
>>> 6. django-authtools passes on travis-ci.org tests, and, as far as I
>>> know, enforces c
Check out django-authtools
https://django-authtools.readthedocs.org/en/latest/
Provides a few abstract base classes that make this very easy to
accomplish. I'm sure there are other 3rd party apps doing the same.
On Thursday, September 12, 2013 2:44:53 PM UTC-6, Abdulaziz Alfoudari wrote:
>
>
+1 on a better way to do field errors.
An alternate would be to implement a method that does this.
def field_error(self, name, error):
> self._errors = self._errors or ErrorDict()
> self._errors.setdefault(name, ErrorList())
> self._errors[name].append(error)
Having to raise a Valid
+1
This would be great.
On Thursday, March 7, 2013 12:42:29 PM UTC-7, Bruno Renié wrote:
>
> Hello,
>
> There was some discussion on the current limitations of the ModelForm
> API in the past couple of days on IRC, I'd like to make a proposal to
> address some of them.
>
> I wrote django-flop
bump. Any chance we can get this looked at?
On Thursday, September 13, 2012 2:55:56 PM UTC-6, Aaron Merriam wrote:
>
> I'm curious if someone can shed some light on ticket #14087 (
> https://code.djangoproject.com/ticket/14087)
>
> It appears there is a pull request open o
This is great. +1. Better than an additional hook.
On Friday, November 16, 2012 7:09:40 AM UTC-7, Daniel Sokolowski wrote:
>
> I like this approach.
>
> *From:* George Hickman
> *Sent:* Thursday, November 15, 2012 7:27 AM
> *To:* django-d...@googlegroups.com
> *Subject:* Re: Class bas
thinking of? I can’t
> think of any that that the base views do to warrant your statement.
>
> *From:* Aaron Merriam
> *Sent:* Friday, November 09, 2012 3:12 PM
> *To:* django-d...@googlegroups.com
> *Subject:* Re: Class based views: A standard hook for
> http-me
and essentially duplicate the original
> dispatch method with an init call added in.
>
> Cheers,
> Jordan
>
> On Fri, Nov 9, 2012 at 6:25 PM, Russell Keith-Magee <
> rus...@keith-magee.com > wrote:
>
>>
>>
>> On Fri, Nov 9, 2012 at 1:05 PM, Aaron
Diederik van der Boor
>
> > wrote:
>
>>
>> Op 7 nov. 2012, om 17:49 heeft Aaron Merriam het volgende geschreven:
>>
>> I wanted to post and modified version of a gist posted earlier in this
>> thread.
>>
>> https://gist.github.com/4032482
&g
I wanted to post and modified version of a gist posted earlier in this
thread.
https://gist.github.com/4032482
I originally implemented the original structure of having an `init` hook
which was called between setting request, args, and kwargs, but i quickly
found that I had a few situations wh
Just wanted to put my +1 into this thread. I've been fighting for a clean
way to implement permissions in class based views and the 'init' method
would help my implementation be a lot more DRY.
On Wednesday, October 31, 2012 12:42:33 PM UTC-6, Jordan Hagan wrote:
>
> Diedreik,
>
> Thanks for yo
I'm curious if someone can shed some light on ticket #14087
(https://code.djangoproject.com/ticket/14087)
It appears there is a pull request open on github to fix this issue
(https://github.com/django/django/pull/178)
This recently became a problem when we separated out a few apps into
individ
Tai, we use that same structure at my work and so far it has worked well.
https://github.com/fusionbox/django-fusionbox/blob/master/fusionbox/db/models.py
It also extends well. You can define queryset methods elsewhere and then
inherit from them on multiple models to reuse those methods easily.
19 matches
Mail list logo