Hey Steve, Thanks for the suggestions. Setting aside the matter of using extends vs. include, or using data-driven menus vs. hardcoded menus, the key issue is how to figure out which of the links corresponds to the current page.
>From your code sample, it looks like you're comparing request.path with the URL of your custom Page object. (Comparing URLs is basically the idea of http://gnuvince.wordpress.com/2007/09/14/a-django-template-tag-for-the-current-active-page/, also.) However, I don't think comparing URLs is really a perfect solution. I think of a "logical page" as basically a view called with a particular set of *args and **kwargs. But many different URLs can map to the same logical page, and a URL equality test only matches one of them. What seems harder to write (without modifying Django) is something that will match the same logical page regardless of variations in the URL. I suppose it's possible to write a middleware that saves the view, *args, and **kwargs as attributes of the request object, and then a template tag that does something like this: (request.view, request.args, request.kwargs) == resolve(reverse(urlpattern_name, *urlpattern_args, **urlpattern_kwargs)) But that seems like an inefficient roundabout way to do it... I just noticed that there was a discussion about this on the django- users group a few days ago: http://groups.google.com/group/django-users/browse_thread/thread/f2a68fb2a2c7e0e0 where the ideas were 1) compare the path or 2) manually specify the active page name in a {% block %} tag in each template, and use CSS magic to do the rest. I'm just thinking it would be nice for Django to have a better way to do this built in... -Jesse On Oct 16, 8:12 pm, Steve Holden <[EMAIL PROTECTED]> wrote: > Jesse Young wrote: > > I'm guessing it's somewhat common (as usual, I think it's common > > because I do it) to put several navigational links in a template that > > is included from several other templates, e.g.: > > > <a href='{% url page1 %}'>Page 1</a> > > <a href='{% url page2 %}'>Page 2</a> > > ... > > <a href='{% url pageN %}'>Page N</a> > > > But also, it's helpful to indicate where the user currently is in the > > navigational hierarchy, e.g.: > > > <a href='{% url page1 %}'>Page 1</a> > > <a class='active' href='{% url page1 %}'>Page 2</a> > > ... > > <a href='{% url pageN %}'>Page N</a> > > > With Django I don't know of a convenient built-in way to do this. One > > could copy and paste N slightly-different versions of the navigational > > links template, but that isn't maintainable. One could manually pass > > in an extra context parameter in each of the N views, and add {% if %} > > tests in the template for each of them, but that's tedious. > > > What I want is the ability to write a custom template tag that uses > > the same parameters as the tag {% url pageN %}, but which acts as a > > conditional and does something different if the parameter matches the > > currently active urlpattern. E.g., I could write a block tag {% > > ifactive pageN %}: > > > <a {% ifactive page1 %}class='active'{% endifactive %} href='{% url > > page1 %}'>Page 1</a> > > <a {% ifactive page2 %}class='active'{% endifactive %} href='{% url > > page2 %}'>Page 2</a> > > ... > > <a {% ifactive pageN %}class='active'{% endifactive %} href='{% url > > pageN %}'>Page N</a> > > > It doesn't seem like this can be done with standard Django because the > > request doesn't have a reference to the URL pattern that was actually > > used. My idea (implemented in my local version of Django) was to > > modify RegexURLResolver to return the urlpattern that was used, and > > store that (as well as the kwargs) as a property of the request. > > > Does this seem like a useful patch? Or is there a better way to > > accomplish this? > > Some general advice, which may not all be relevant to your specific > circumstances. While including templates has its place, it's often > simpler and easier to use template inheritance ("{% extends ... %}") > instead. Look at context managers. You want to avoid doing as much of > that stuff in templates as you possibly can - it can get ugly real > quick, whereas in pure Python it's much more natural to express that > sort of thing. > > Have the context manager build an appropriate list for the specific > page, and then just have the template render whatever list the context > manager builds. There's a balance to be struck between template > complexity and Python complexity. > > This can also keep your template structures simpler. In holdenweb.com > more of the pages are stored in the database, and each page can be > associated with a section. You will notice, for example, on > > http://holdenweb.com/contact/ > > that the "Contact Holden Web" link in the left-hand nav bar isn't > actually a link (I have an aversion to self-linking pages). The part of > the context manager that builds the left-hand nav data reads > > lNavSecs = Section.objects.filter(secpos="L").order_by("secsequence") > for sec in lNavSecs: > sec.pages = Page.objects.filter(pagsecid=sec.secid). \ > exclude(pagsequence=0).order_by("pagsequence") > hpdict["lNavSecs"] = lNavSecs > > The navigation is rendered in the base template, which all other site > pages (except the front page) extend, and the template section that > renders it reads > > </div> > {% for sec in lNavSecs %} > <h2><img src="/images/lowerlevel/{{ sec.secpath }}.png" alt="{{ > sec.sectitle }}" /></h2> > <div class="content" id="SecNav{{ sec.secid }}"> > <ul> > {% for p in sec.pages %} > {% ifequal path p.pagpath %} > <li>{{ p.pagdoctitle }}</li> > {% else %} > <li><a href="/{{ p.pagpath }}/">{{ p.pagdoctitle }}</a></li> > {% endifequal %} > {% endfor %} > </ul> > </div> > {% endfor %} > </div> > > It's usually easier to iterate over a sequence of some kind than putting > lots of special-cased stuff in the template. > > Hope this helps. > > regards > Steve --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
