Sections

[Wesley St.Clair]

I feel like I am missing something obvious, but I have been struggling with this for a couple of hours and haven't figured it out.  How do I override the sections query that is used by the section_menu template tag?  It seems like I should be able to add kwargs={'sections': my_sections} to my url patterns to override the default sections query in SectionMenuNode, but I'm not sure exactly what my_sections should be.  Before digging into the code, I assumed it would be a queryset, but this does not appear to be the case.  Specifically, I don't understand what this line of code is doing (armstrong.core.arm_sections.template_tags.section_helpers.py).

            sections = self.sections.resolve(context)

Any help is greatly appreciated.

Thanks!

Wes

[Dave McLain]

Wes -

That is a standard way of resolving template context variables during render time. In order to replace the queryset in the template using something like:

{% section_menu sections=your_queryset %}

This will require using a view or context processor that populates your template context with a variable containing your custom section queryset.

dave

[Wesley St.Clair]

Thank you for the information!  That cleared things up for me.

In order to use my own queryset for sections, I am subclassing the Armstrong generic views and overriding the get_context_data method to add my_sections to the returned context.  This ends up being very little work now that I have a better idea of what is going on, but it does require me to maintain my own views (kind of).  I wonder if there shouldn't be a more global method of defining the sections queryset. Thoughts?

Wes

[Dave McLain]

Determining where to put the logic for building the navigational elements on the Texas Tribune is a source of constant back and forth. Three solutions come to mind -- Class based view mixins, template context processors and custom tags. They all have their pros and cons:

CBV Mixins

• Pros: You can very quickly see where all your DB calls are coming from and it just feels like a better separation of logic in the Model/View/Controller mold (or Model/Template/View in django parlance)
• Cons: Every time you write a new view you have to make sure you're bringing in all the right stuff to make your navigational fields work

Context Processor

• Pros: This is really what context processors are for
• Cons: They get run no matter what, so when you start doing logical things like caching a fancy, query-created menu, you might still end up paying for those trips back and forth to the database, even though you're just going to pull straight out of cache.

Custom Tags

• Pros: They can really make your templates a lot simpler. Also, there's basically nothing you can't do once you're writing your own tags
• Cons: You can quickly get to a point where your tags are complicated and something like {% section_menu %} is doing dozens of queries, which doesn't feel right. There has been talk about the Django templating language and making the internals work a lot faster in future versions, but it's not yet clear what that might mean for custom tags.

All that being said, it would be a logical refactoring of https://github.com/armstrong/armstrong.core.arm_sections/blob/master/armstrong/core/arm_sections/templatetags/section_helpers.py#L25-28 to pull the highlighted section into a get_queryset method so that it would be easier to subclass and override.

Dave McLain

The Texas Tribune - Software Engineer

823 Congress Ave., Suite 210 Austin, TX 78701

www.texastribune.org

M (512) 203.5931 F (512) 716.8601

[Wesley St.Clair]

Ah... Context Processor would be the "more global" method I was looking for.  The database performance hit may be there, but it can be circumvented without too much problem.  Cache the views and load the more dynamic content (reader comments, ads, etc) via AJAX calls after the page loads.

I've learned a lot today.  Thanks again!

Wes