Re: Extending the URL Dispatcher (GSoC 2015 proposal)

First of all, thanks for the feedback. There are some good points here that I hadn't thought about. Behaviour similar to a `ContinueResolving` exception is one of the things I was aiming at. However, I can't see how to raise this in a view while maintaining backwards compatibility with view

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

You're correct, the first app has priority. Only management commands used to work the other way round. (Remind me who made that change?) -- Aymeric. > Le 3 mars 2015 à 20:07, Marc Tamlyn a écrit : > > I believe we standardised priority order such that earlier in the

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

I believe we standardised priority order such that earlier in the list always takes priority. Historically we had different orders for different things (templates, template tags, static files etc). In any case, I don't think this should be a blocker and I'm in favour of including it as

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

I agree: providing a default login template would help. Getting started with contrib apps should be as easy as possible. However the current proposal is backwards incompatible for users who define the login template in one of their apps that comes before django.contrib.auth in INSTALLED_APPS

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

So, should I create a ticket? On Tuesday, March 3, 2015 at 4:05:01 PM UTC+3, Ilya Kazakevich wrote: > > Hello, > > When I use Django auth, I need to provide login.html myself. But Django > encourages applications to have default templates which can be overwritten > by user (via

Re: does django-admin need a man page?

Is anyone interested in updating Django's man page? It's a bit embarrassing that the one that ships with 1.7 includes commands that no longer exist (cleanup, install (never heard of that one before), etc.). The fact that it is so outdated and that we've gotten no complaints about it is why I

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

I agree: adding template from example is good idea! And I believe it will be used at least by newbies who just study Django auth system and by people who just need prototype. Providing default is better than copy/pasting example from docs. On Tuesday, March 3, 2015 at 5:26:10 PM UTC+3, Marc

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

I can see the merit of including our documented example as an actual template as a starting point. It's unlikely to be used exactly as is very often but it reduces getting started friction for some users - "huh this view doesn't work, better go read the docs" I'd perhaps be inclined to include it

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

I do not think admin templates should used. But something very simple and dumb (that looks similar to browser HTTP auth window). Here is example: http://pastebin.com/nnX36RB6 Css should be moved to static files, of course, to make this template cleaner and slightly more customizable. Imagine

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

The admin templates extend "admin/base_site.html" and rely on the presence of specific template blocks so I don't think it's appropriate for those dependencies to be added to contrib.auth. I'm curious to see what content you would propose for a default template. Typically I've seen login

Suggestion: add default "registration/login.html" to django.contrib.auth

Hello, When I use Django auth, I need to provide login.html myself. But Django encourages applications to have default templates which can be overwritten by user (via filesystem.Loader, for example). I suggest to provide default login.html with simple HTML form. User may always overwrite it.