A Top-Level Django Index for the root URL

[Ben Pritchard]

Hello everyone,

First, a warning: I'm a total noob but I have really enjoyed working through the tutorial.

The first post-tutorial thing I've done is construct a top-level page that gets rendered using:

urlpatterns = patterns('',
    (r'^$', 'mysite.views.index'),   

This was necessary because since I've added (r'^polls/', include('mysite.polls.urls')), the link http://localhost:8000/ failed to render a response (which is understandable).


The intention is that this page will list all my of sandbox projects.  So at the moment it just links to http://localhost:8000/polls but (a) coding the link seems like a HTML solution rather than a Django solution and (b) it will be tedious to update this html template file each time I add a new subsection to my site.

So, is there a Django solution that can list the available mini-sites that are available?

I look forward to any help that someone can offer me.

Thanks,
Ben


p.s.: I've searched the mailing list archives but (not surprisingly) hits for "top-level" "site" "index" "projects" and "list" are producing rather a lot of hits!!  One candidate I've found is the sites framework?  Is the answer hidden in there somewhere?

[Wayper, Paul]

 

From: Ben Pritchard
Subject: A Top-Level Django Index for the root URL

The intention is that this page will list all my of sandbox projects.  So at the moment it just links to http://localhost:8000/polls but (a) coding the link seems like a HTML solution rather than a Django solution and (b) it will be tedious to update this html template file each time I add a new subsection to my site.

So, is there a Django solution that can list the available mini-sites that are available? 

 

 

Hi Ben,

 

I'm in that same boat, and I'm considering my options:

 

My first attempt was to change the way the INSTALLED_APPS is built - as detailed in http://www.mabula.net/tbfw/2008/11/07#2008-11-07-dont-repeat-yourself-tng - and to write a middleware which presented the 'shown apps' as a structure to read in the template.  Following the principle of Don't Repeat Yourself, this then lists each application once along with all the information relevant to it.  This is, however, a fairly heavy-handed approach in my opinion as it means re-jiggering things in settings.py.

 

My second idea, not yet implemented, is to write a middleware which introspects the list of URLs.  If it finds one named 'index' (where 'named' means 'named or with a view named'), that's taken to be the root URL.  Anything with '(.*)_index' that is in the same directory as the root URL is taken to be an application - that URL becomes the application URL path.  Once you're in that application, anything with '(.*)_index' in the same directory as the application's URL path is a sub-menu of that application and so forth.  That makes it relatively easy to list URLs in a structure that most projects follow without repeating the application structure elsewhere or having to do terrible things to settings.py.

 

My question is: is the second idea Django-ish enough?  I'd like some feedback from the list before I start work on it as to whether it's a dead end, whether there's a better way, or just to hear any improvements on that scheme.

 

Your thoughts?

--
Paul Wayper
SYSTEMS ENGINEER
TransACT

Telephone: 02 6229 8026
Mobile: 0422 392 081

PO Box 1006, Civic Square  ACT  2608

www.transact.com.au