io ho preso l'approccio "low tech" di Jarret Hardie in una simile, err ... contesto (sì, è un gioco di parole ... che non renderà perfettamente senso per voi a meno che non vi dico che io non stava facendo navs ma impostando il colore del bordo dei pulsanti per mostrare quale era stato premuto).
Ma la mia versione è un po 'più compatta, penso. Invece di definire solo una semplice barra attiva della variabile di contesto nella vista, restituisco un dizionario, ma sempre con una sola coppia chiave-valore: ad es. activebar = {'foo': 'active'}.
Quindi nel modello scrivo semplicemente class = "{{activebar.foo}}" nell'ancora foo, e corrispondentemente negli altri ancore. Se solo activebar.foo è definito per avere il valore "attivo" allora activebar.bar nella barra di ancoraggio non farà nulla. Forse "fallire silenziosamente" è il giusto discorso di Django. E Bob è tuo zio.
EDIT: Oops ... un paio di giorni sono passati, e mentre quello che avevo scritto sopra ha funzionato per me un problema è apparso quando ho inserito nella barra di navigazione un ancoraggio con una nuova finestra come destinazione. Sembrava essere la causa di uno strano problema: dopo aver fatto clic sulla nuova finestra (scheda in Firefox) e poi tornare a quello da cui era stata lanciata la nuova finestra, le porzioni del display sotto la barra di navigazione diventavano vuote ogni volta che spostavo rapidamente la cursore sopra gli oggetti sulla barra di navigazione --- senza fare clic su nulla. Ho dovuto forzare il ridisegno dello schermo spostando la barra di scorrimento (non una pagina di ricaricamento, anche se anche questo ha funzionato perché comporta un ridisegno dello schermo).
Sono troppo un noob per capire perché potrebbe accadere. Ed è possibile che io abbia fatto qualcos'altro che ha causato il problema che in qualche modo è andato via. Ma ... ho trovato un approccio più semplice che funziona perfettamente per me. Le mie circostanze sono che ogni modello figlio che viene avviato da una vista dovrebbe causare la visualizzazione di un elemento della barra di navigazione come "attivo". In effetti, quell'elemento della barra di navigazione è quello che ha lanciato la vista che ha lanciato il modello figlio --- il solito affare.
La mia soluzione --- prendiamo come esempio una voce di "accesso" per la barra di navigazione --- è per inserire questo nel modello secondario che contiene il modulo di accesso.
{% block login %}active{% endblock %}
L'ho messo sotto il cartiglio ma non credo che il posizionamento sia importante. Poi nel modello principale che contiene la definizione barra di navigazione, per il tag li che circonda l'ancora per la voce di accesso barra di navigazione ho messo ... beh, ecco il codice:
<li class="{% block login %}{% endblock %}"><a href="/mysite/login">Login</a></li>
Così, quando il template figlio è resa la genitore mostrerà l'elemento della barra di navigazione come attivo, e Bob è ancora tuo zio.
L'approccio del dizionario che ho descritto sopra era per mostrare quale di una linea di pulsanti era stata premuta, quando erano tutti sullo stesso modello figlio. Funziona ancora per me e dal momento che è coinvolto un solo modello figlio, non vedo come il mio nuovo metodo per i navbar possa funzionare in quella circostanza. Si noti che con il nuovo metodo per le viste navbars non sono nemmeno coinvolte. Più semplice!
Hai controllato? http://stackoverflow.com/questions/1024168/django-is-there-a-better-way-to-bold-the-current-page-link – rinti
Questa soluzione CSS sembra molto difficile da mantenere e richiede di aggiungere informazioni in 3 posti diversi. – Boris