newforms-admin: Handle relative paths in documentation templates

I cannot recreate any problem with the user-tools links in trunk r7776. At any rate problems with trunk admin are not worth fixing at this point, so I looked to see if this all works properly on newforms-admin, and here I do see one problem. So I'm moving this ticket over to newforms-admin for fixing that problem.

Where I see a problem in newforms-admin is when you follow the "Documentation" link (I am running with the patch for #6962 so the Documentation link actually works). Once you have followed the "Documentation" link the user-tools links start to exhibit problems. On the main Documentation index page there is a link to Documentation which is now (broken) '/admin/doc/doc' (change password and logout are broken also). Similarly if you go to /admin/doc/views the user-tools links are /admin/doc/views/doc/, /admin/doc/views/pasword_change/, etc. But if you go to a specific view detail the userlinks block is redefined in the template and 'Documentation' is dropped (why? it would be nice to have a link direct back to doc index instead of having to backtrack two pages) while change password and logout end up referring to the right urls, but only because the proper number of ../..s are hardcoded into the template which is an approach most of the other templates seem to have been moving away from.

Changeset 7638 made changes so that the admin site determined the root admin path and passed that value into templates. Many of the block userlinks overrides were removed from the admin templates. However this changeset doesn't seem to have done anything for the admin doc templates. I think the work of changeset 7638 needs to be extended to handle the doc views and templates.

Marking nfa-blocker since technically this is a regression from trunk, where all these links work properly.

I introduced new base template for admin docs which removes Documentation link from userlinks. Also all views from admindoc application now returns root_path template variable to properly create urls in templates.

(In [7934]) newforms-admin: Fixed #7466 -- Generate a root_path for admindocs views so the userlinks are properly linked. Thanks handelaar for the report.

Not all relative links are working after the fix. For example, if you go to Documentation -> Models -> auth.Permission the links are relative to that page and so do not work. Similarly for Documentation -> Models -> admin.LogEntry?. I put a print statement in where the root_path is calculated and it seems the problem is the app_label for these is 'contenttypes' instead of 'auth' or 'admin':

Django version 0.97-newforms-admin-SVN-7939, using settings 'xword.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CTRL-BREAK.
root_path for request.path /admin/doc/models/auth.group/, app_label auth, model_name group is: /admin/
[17/Jul/2008 09:11:52] "GET /admin/doc/models/auth.group/ HTTP/1.1" 200 2572
[17/Jul/2008 09:12:08] "GET /admin/doc/models/ HTTP/1.1" 200 3259
root_path for request.path /admin/doc/models/auth.permission/, app_label contenttypes, model_name permission is: /admin/doc/models/auth.permission/
[17/Jul/2008 09:12:11] "GET /admin/doc/models/auth.permission/ HTTP/1.1" 200 3262
[17/Jul/2008 09:24:40] "GET /admin/doc/models/ HTTP/1.1" 200 3259
root_path for request.path /admin/doc/models/auth.permission/, app_label contenttypes, model_name permission is: /admin/doc/models/auth.permission/
[17/Jul/2008 09:24:50] "GET /admin/doc/models/auth.permission/ HTTP/1.1" 200 3262
[17/Jul/2008 09:26:03] "GET /admin/doc/models/ HTTP/1.1" 200 3259
root_path for request.path /admin/doc/models/admin.logentry/, app_label contenttypes, model_name logentry is: /admin/doc/models/admin.logentry/
[17/Jul/2008 09:26:06] "GET /admin/doc/models/admin.logentry/ HTTP/1.1" 200 3250

I didn't do an exhaustive search nor much experimenting with routes other than 'Models' and I've run out of time for now so figured I'd just report this much.

Removing nfa-blocker because I don't believe fixing the remaining links should hold up a merge to trunk. Most of the problem is fixed in the current code.

Fixed (well, for the most part) in [8718].