#36941: Enhancement Proposal for querystring template tag: Support for dynamic
context-based keys
-------------------------------------+-------------------------------------
Reporter: Hristo Trendafilov | Owner: (none)
Type: | Status: new
Cleanup/optimization |
Component: Template system | Version: 5.2
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Hristo Trendafilov:
Old description:
> **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' %}`
>
> 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, 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.
New description:
**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, 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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/36941#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019c8a15799c-a5c0a4f3-aa81-4c3a-b7fc-542fefe718e0-000000%40eu-central-1.amazonses.com.
