Monday, August 5, 2013

Re: How to store position of current/active navigation entry




On Sun, Aug 4, 2013 at 6:39 AM, DJ-Tom <eventellis@gmail.com> wrote:
Hi,

I don't think I know how to actually do what you are suggesting.

Lets say I have three menu options with the following URLS:

"One" - /one/show
"Two" - /two/show
"Three" - /three/show

Currently I have somthing like this in my main.html page template:

        {% if navi %}
            {% for entry in navi %}
                <li class=""><a href="{{ entry.href }}">{{ entry.name }}</a></li>
            {% endfor %}
        {%  endif %}

With the following view function:

def show_mainPage(request):

    navigation = [ {'href':'/one', 'name':"One"},
                   {'href':'/two', 'name':"Two"},
                   {'href':'/three', 'name':"Three"}]
    return TemplateResponse(request, 'main_page/main.html', {'navi': navigation, 'main_settings':main_settings.objects.get(id=1)})

So how would I set the "active" CSS class in my template for the correct nav entry?

Perhaps I don't understand the nature of the problem.  I'm assuming that the nav entry to be highlighted by default is a function of which page is being viewed.  Further, I presume that you know which page to display because a GET request was issued (either vanilla or AJAX), and the path part of the URL (possibly in combination with query parameters, if you have a truly complex scheme) allows the combination of your urlpatterns and view functions to know what to render.  It follows (to me, at least) that the information available in the request is enough to know which item should be highlighted.

If that's correct, then nclude whatever attribute you need to on a navi entry object that it can be compared with a value derived from the request (either in your view, in a template tag, or (best) placed in the context by a template context processor (still has to be a request context to give you access to the request object)).  Use this with an "if" tag to control adding a class to the "li" element (for instance) which, in common with simple CSS, highlights it.

There are also schemes with mutually unique classes on your "li" elements, the same, or related, class as for the one to be highlighted on a containing element, and a set of CSS rules, one for each highlight-able menu item, to highlight the "li" if the outer class is an ancestor of the corresponding "LI"'s class.  This is messy, potentially requiring dynamically generated CSS if your Nav tree changes dynamically.  The use case is where you are pulling new data through AJAX to morph the page into a new one, so that a new menu item should be highlighted.  The JavaScript need only change the class on the outer element, allowing your to to avoid having to loop across the nav removing the one highlight class (from the first approach), or from the one that your JavaScript knows was highlighted, before applying it to the newly selected "li" (mutually unique classes are still a help to this JavaScript).

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home


Real Estate