App Name In Admin
Steve Phillips
Around two weeks ago I inquired about customizing the "App Name" in
the the Admin Interface. I came up with a solution which involves
copying the original "django.contrib.admin, sites.py" over to project
level and did what I needed to do to make it so I could have a custom
app name and use that instead of using the default django admin site.
Now, I can use this going forward in future projects. So far it hasn't
caused any problems that I have noticed but the only thing for me to
figure out is fixing the breadcrumbs when I am in the add form. The
breadcrumbs are perfect when I am in a change list and higher.
Here's what I have to do going forward in future projects.
Like when I go and do a "manage.py startproject", after the the
project files are created I than copy over my sites.py(myAdmin.py).
Register my models with myAdmin and go on my merry way. When I
register my model I do it like normal but I throw a extra argument on
the end which is called "show_app_name='whatever I want'". Then that's
where I had to go into the sites.py file and add and/or change a few
lines.
If anyone is interested specifically what I did to my "myAdmin.py" let
me know and I will post or reply directly. I'm not totally sure what
the rules are, if any as far as posting modifications to the original
django code so I just want to be safe on that one. I would say that
it's only 7 to 10 lines of code.
Why copy the myAdmin.py instead of just importing it though python?
Well that's sort of because of my own personal situation and I will
get to that later.
I have 2 computers at work and 2 at home. When I send projects and/or
apps to work or home or vice versa I don't want to run into a instance
where I one day i forget to send that too.
I will admit that its not pretty but it works. I saw on some django
blogs about people copying functions and classes from particular admin
.py files and changing them at project level and doing that for
several projs or apps which I think is a little over the line. But
they did make me realize that there are some instances where you just
have to do it, for now anyway. (totally unrelated to my issue). So i
do realize this sort of violates the DRY principal but, I feel that it
helps me understand the django framework a little better and I don't
and won't have to touch the default sites.py.
Now I am interest in what some others in the group have done for this
issue(if they wanted or needed to). Not the code directly but sort of
the procedures as I am open to other ideas. I don't think I want to
use this as a permnent solution.
Thanks,
Steve P