Whilst this works, I'm not sure it was the intention in the design of swappable. Clever though and it would allow the single-app approach.
However, we still have the issue of different forms, urls, views etc all based off the changed model. Making these change automatically would be horrible. I still think a second app is a better plan. If we are going to do this I think it is worth revisiting class basing the with views. A decent chunk of work was done on this at some point, and there are other implementations in the wild. It makes having the two separate versions much simpler in terms of swapping out form classes etc. One if the major issues was the lack of quality tests for some of the views. Marc On 19 Sep 2013 19:25, "Luke Sneeringer" <l...@sneeringer.com> wrote: > > > On Sep 19, 2013, at 11:33 AM, Aaron Merriam <aaronmerr...@gmail.com> > wrote: > > 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. > > https://code.djangoproject.com/wiki/ContribEmailAuth > > The problem you've got here is how it knows to *not* install EmailUser. If >> it's a model defined in d.c.auth.models, it will get installed, >> irrespective of whether it is AUTH_USER_MODEL or not. > > > I wanted to verify this so I ran some basic tests and turns out that > swappable already does the correct thing. If two models have the same > swappable value, only the one referenced in settings will be > used/installed. This makes it practical to include a second user model in > d.c.auth.models without any changes to model loading or the swappable > mechanism. > > > Precisely. I think I originally stated my thinking quite poorly, which > caused a great deal of confusion (sorry about that). I didn't know that > swappable existed, and was proposing a mechanism that acted similarly to > that. But, since swappable *does* exist, it seems like it's the best > mechanism. I had originally made the same error that Marc made. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
