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
-~----------~----~----~----~------~----~------~--~---
