I've learned a lot today. Thanks again!
> 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/... 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
> On Sun, Mar 11, 2012 at 6:16 PM, Wesley St.Clair <wes.stcl...@gmail.com>wrote:
>> 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
>> On Sun, Mar 11, 2012 at 3:20 PM, Dave McLain <dmcl...@gmail.com> wrote:
>>> 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
>>> On Sun, Mar 11, 2012 at 1:56 PM, Wesley St.Clair <wes.stcl...@gmail.com>wrote:
>>>> 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
