pass the context to extra_context functions

[bennydaon@…]

I found it helpful for extra_context functions to have access to the context.
The change is in line 80:

<        if callable(value):
<            c[key] = value()

>        if callable(value):
>            c[key] = value(c)

I'm not sure who decides on whether it should go to the version - it does changes the API

[Malcolm Tredinnick]

(Fixed description formatting.)

What file are you trying to change here? What is an example use-case?

[bennydaon@…]

This change is to list_detail.py and I use it for the function display_pages:

def display_pages (c):
        ''' return an HTML string that renders: "1 2 3 4 ..." and has a link for all pages except the current. '''
        return ' '.join([p==c['page'] and '%s&nbsp;' % p or '<a href="/foo/page/%s">%s&nbsp;</a>' % p for p in range(1, c['pages']+1)])

[Chris Beaven]

Sounds like you should be doing this as a template tag, not an extra_context function. Also taking into consideration the fact that this would break everyone's current functionality, I'll call it and say wontfix.

[sciyoshi@…]

I'd like to ask for this again. I have the following situation: two models, Category and Post, where each Post has a Category. I want object_detail for Categories to display a list of the category's posts by {% extend %}ing 'post_list.html'. Unfortunately, doing this any other way (i.e., a context processor or a list_detail view on the Post model) are either ugly or require multiple lookups for the category. With this, everything is much easier:

(r'/categories/(?P<slug>.+)/$', object_detail, dict(
    queryset=Category.objects.all,
    template_object_name='category',
    slug_field='slug',
    extra_context=dict(
        post_list=lambda context: context['category'].get_posts(),
    ),
))

Note that you can add this functionality without breaking anything:

if callable(value):
    try:
        c[key] = value()
    except TypeError:
        c[key] = value(c)

[Malcolm Tredinnick]

Please do not reopen tickets that have been marked as wontfix. We ask this for a reason: so that we don't continually have requests reopened just because people don't agree with them. If you are unhappy with the resolution, the contributing.txt document (also available in our documentation section online) explains what the next step is. Read the section in there about ticket statuses.

I am not commenting on your request, since following the normal procedure is important here.

[daonb <bennydaon@…>]

I've opened this ticket, but fully agree with the decision to close it as 'wontfix'. If you need to access any of the context parameters, you're better of using a customer templatetag. I found the use of templatetag make reuse easier and the code more readable.

Templatetags are quite easy to write and can accept any number of parameters. If I understand your issue, you need a template tag that will return a post list based on the 'category' parameter:

{% get_posts for category as post_list %}

You can find an explanation on how to write your own templatetags ​here.

Hope it helps.

[Samuel Cormier-Iijima <sciyoshi@…>]

The problem I was having was that context variables set in the child template (through a template tag) didn't seem to be accessible from the parent. The problem was that I wasn't setting the variable inside a block tag, so it wasn't getting pushed onto the parent's context. Anyways, although I think it would be nice for small things like this to not have to write a whole template tag, I respect the developers' decision to wontfix this.

Thanks,
Samuel