Re: Why is Admin login template at admin/login.html instead of registration/login.html?

Hi Carl,

Am 23.07.2015 um 20:07 schrieb Carl Meyer:
> Of course it's _possible_ to have just a single login page instead, if
> you want that, but it's not at all clear to me that that's better. I
> prefer to keep the admin relatively separate from the public site.
>
> And I think the same is true for password-reset etc. I'd prefer to leave
> the admin with its own pages, styled consistently with the rest of the
> admin, and design my own pages for public users, consistent with the
> design of the rest of the public site.

Yes, I certainly see your point. If I could start all over with my first (and now major)
Django project, or in the mid-term future, I'd probably also do it like this.


Allow me to add some background info:

When I started with Django and worked through the tutorials, augmenting and building my
first project in the process, it was very nice to get quick success and highly useful
results with the Django Admin. Also the first custom view was quickly written thanks to
the forms and templates features.

But... while I understand HTML and CSS at a logical level, I'm a horrible web designer.
For my first view and its related template, I quasi had nothing; no basis that looked
anywhere near visually acceptable, especially none that came with a nice top navigation
bar, user links, etc. And so what did I do, against all advice and documentation? I used
the Admin templates as a basis for my custom views. (I hope than anyone will ever talk
to me again after this. ;-) )

Worse, soon I had a model that I wanted users to be able to deal with almost like
administrators: (View,) create, edit, and delete instances at will. The only difference
to "real" is_staff admins was a filtered/limited QuerySet. But with changelists that
support pagination, filtering, sorting and searching.

Really, until today I have no idea how I can achieve (i.e. duplicate) such functionality
in custom user views (without reinventing the wheel). (Maybe class-based views can do
that, I'm still with classic function-based views, and I really don't know if this makes
a difference.)

And so I got where I am now: Most of my regular users are also admin users, and they
don't even know the difference.

And so while I strive to get things properly separated again, I bridge the time by using
common designs at least for the custom and admin auth views. (Bootstrap is really
perfect for me, I wished I had it available from the very beginning. Would then never
have used the admin templates in custom views in the first place.)

> Presuming we made the admin use its own templates for all of this, you
> could achieve what you want by also overriding the admin templates and
> just making them inherit everything from your templates. A tiny bit of
> boilerplate, but not much.

Yes. Indeed, thanks to the AdminSite object, in an app's admin.py file, even a simple

admin.site.login_template = "registration/login.html"

is enough – this is the exact live code that I use now to override the
"admin/login.html" default.


Best regards,
Carsten

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/55B24485.3030508%40cafu.de.
For more options, visit https://groups.google.com/d/optout.