Re: Change username field widget in AuthenticationForm based on USERNAME_FIELD
This seems like a reasonable change. I don't love the fact that the contrib.auth built in forms quasi support custom user models, as it leads to a less clear delineation about what parts of contrib.auth are tightly coupled auth the default User model. https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#custom-users-and-the-built-in-auth-forms This doesn't warrant a backport for 1.6 though - as it is currently easy to override this in your own form, and 1.6 is in feature-freeze beta. -Preston On Friday, August 2, 2013 9:20:58 AM UTC-7, Anders Steinlein wrote: > > Hi all, > > I have implemented a custom user model that extends AbstractBaseUser, > where an EmailField is set as the USERNAME_FIELD. Logging in with a default > auth login view and AuthenticationForm works nicely, however, the username > field is still a CharField and thus rendered as a regular input field. I'm > using Django 1.6 where I was expecting a type='email' input field. > > How about we change the widget of the username field in > AuthenticationForms __init__ method based on USERNAME_FIELD? If yes, would > it be too late to sneak this into 1.6 given the new use of HTML5 input > types? I'm happy to provide a patch. > > > *Anders Steinlein* > *Eliksir AS* > http://e5r.no > > E-post: and...@e5r.no > Mobil: +47 926 13 069 > Twitter: @asteinlein > -- 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.
Re: how get user session name in models django??
Please ask questions about using Django on django-users, and please do not crosspost to both lists. The topic of this list is the development of Django itself. -- 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.
how get user session name in models django??
hello guys!. how get user session name in models django?? i tried: from django.contrib.auth.models import User class myclass (models.Model): def myuser (): user = User.objects.get() return user establec = models.CharField(max_length=200,default=myuser) but that would be wrong ...any idea? -- 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.
Re: Deprecate FCGI support in Django 1.7
Is there a consensus on the project that'll be created to handle this outside of Django? Would be nice to have something to point people to when closing Trac tickets for FastCGI. On Wednesday, July 24, 2013 5:56:45 AM UTC-4, Tom Evans wrote: > > On Sun, Jul 21, 2013 at 8:28 AM, Some Developer > > wrote: > > On 21/07/2013 05:08, Curtis Maloney wrote: > >> > >> I wasn't aware there was a particular performance issue, but I'll > >> certainly keep it in mind. > > > > > > Take a look at this: > > > > http://www.peterbe.com/plog/fcgi-vs-gunicorn-vs-uwsgi > > > > I've probably already said it but if you want some help with this > project > > I'd be interested. > > Did you notice that the first thing that anyone does when benchmarking > HTTP servers is that they reduce the work being done by the server so > that it is trivial. That link explains it best, if you throw away > everything that Django provides and simply use it to render a static > string, then uWSGI is faster than gunicorn, which is faster than FCGI. > If you leave any of it enabled however, they all benchmark at > precisely the same speed. > > So, if your django website does not use sessions nor databases nor > templates, then sure, you get a huge performance benefit from fiddling > around with serving mechanisms. > > Cheers > > Tom > -- 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.
