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
>
> 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
>
> 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
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.
ff 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
> believe it to be an inferior approach.
>
> One thing I dislike is having a separate
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,
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 clean commit history (don't know if it is relevant thought).
>>>
>>> 7. usermail has
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
+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
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
inking 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
> h
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 Merriam
&g
van der Boor
> <vdb...@gmail.com
> > 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/40
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
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
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
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
19 matches
Mail list logo
