id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
36941	Enhancement Proposal for querystring template tag: Support for dynamic context-based keys	Hristo Trendafilov	Vishy Algo	"**Problem Statement**

Currently, the `{% querystring %}` template tag treats the keys in kwargs as static strings. While this works for simple use cases, it severely limits the reusability of templates in component-based architectures.

When using `{% include %}` to render a reusable component (like a generic filter, a sortable table header, or a pagination widget), the parameter name (the key) often needs to be dynamic, just like the value.

**The Use Case**

Imagine a reusable include for a sortable column: `sort_link.html`


{{{
<a href=""{% querystring sort_param=field_name %}"">
    Sort by {{ field_label }}
</a>
}}}


If we include it like this:

`{% include 'sort_link.html' with sort_param='order_by' field_name='price' field_label='By Price' %}`

Current Behaviour: It produces `?sort_param=price`.
Expected/Desired Behaviour: It should produce `?order_by=price`.

**Proposed Solution**

Add an optional boolean parameter `resolve_keys` (or similar) to the querystring tag. When set to `True`, the tag will look up the key names in the current context before processing the query dict.

Alternatively, there could be a dedicated template tag that reuses the current `querystring`

{{{
@register.simple_tag(takes_context=True)
def querystring(context, query_dict=None, resolve_keys=False, **kwargs):
    # ... existing logic ...
    
    for _key, value in kwargs.items():
        # Look up the key name in context if the flag is True
        key = context.get(_key) if resolve_keys else _key
        
        if key is None:
            # suggested behaviour - remove this key if in parameters, like if passed `key=None`
            
        # ... correct logic continues ...
       
}}}

**Benefits**

Decoupling: Templates don't need to know the specific backend parameter names.
DRY: One include can handle different filtering/sorting logic across different views.
Consistency: Aligns with how Django handles dynamic values, extending that logic to keys."	Cleanup/optimization	closed	Template system	5.2	Normal	invalid		Yogya Chugh 	Unreviewed	0	0	0	0	0	0