Navigation
Jeff Anderson
I'm curious as to a better solution to the common issue of site navigation.
What I've been doing is just putting the navigation info into the template
directly. This is just about as wrong as it comes for doing navigation bars.
I believe that the "right" way to do it is to have a menu object in the
RequestContext (unless Django best practices have changed since I've
implemented such a menu). Since smug's content comes from a git repository, and
not a Django model, it seems like a common convention may be a good thing.
I purpose an extension to .smug to include navigation information, and a smug
navigation menu that is available to template contexts, just like the regular
smug menu is.
A .smug at the top level for docs.cs.byu.edu may have something like:
nav / Main Page
nav /policies/ Policies
nav /general/ General
nav /linux/ Linux
nav /programming/ Programming
nav /windows/ Windows
The result would be a navigation menu object that the template engine can parse
and build a menu. Ideally, it would be aware as to which navigation item the
current page is accessible through.
A .smug in the /linux/ location may look like:
nav advanced/ Advanced Linux
nav basic/ Basic Linux
nav troubleshooting/ Linux Troubleshooting
Breadcrumb support could also be implemented with the navigation information in
the .smug files. The same .smug file in the linux directory could have the
following line::
navparent /linux/
Breadcrumbs become possible. The top could read:
Main Page > Linux > Advanced Linux > LaTeX
Smarter navigation menus could be built too. Say I want to expand categories if
I'm somewhere in the URL space for that category only. For example, if I'm at
http://docs.cs.byu.edu/linux/advanced/, the menu could render as:
Main Page
Policies
General
Linux
-Advanced Linux
-Basic Linux
-Linux Troubleshooting
Programming
Windows
One drawback to this is that if I wanted to expand *every* category, smug would
have to search for .smug files in the directory tree. To sidestep this, there
could be a way to explicitly specify in a parent .smug file which directories
need to be checked for navigation information.
The main .smug file could have a directive, specifying what directories to
descend to look for additional navigation information:
navchild linux/
navchild general/
With the navchild information available, even more complex navigation menus can
be generated. Navigation menus 3-4 deep are possible, and some CSS and/or
JavaScript can spice up the menu to be just like every other overly complex
navigation menu system on the Internet.
Obviously, caching would be a necessity for some of the more complex
combinations that are available.
It might not be a bad idea to include some template tags that can render both
the smug menu, and the smug navigation menu in different styles.
I wish this was better thought out, and better laid out, but I got the .smug
navigation extension idea after I started writing this e-mail. I'll see if I
can't get something working on a branch in the next several days. Feedback on
this idea before I start coding is appreciated. I'm not exactly sure how this
would work with my prefix feature.
Thanks!
Jeff Anderson
Andrew McNabb
>
> I purpose an extension to .smug to include navigation information, and a smug
> navigation menu that is available to template contexts, just like the regular
> smug menu is.
That's a really, really cool idea. It never even crossed my mind, but
now that you mention it, it seems so obvious. :) I'll have to stew over
the details, but I definitely like the idea. Does anyone else have any
thoughts?
--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
