Feature Request: New parameter for render_to_string() to render part of a template using a selector
With the growing uptake of technologies like HTMX, I would like to see an
additional parameter added to render_to_string(). In my rewritten
definition of render_to_string() below (taken from the docs), I have named
the parameter “part”. In rendering portions of a template for responses to
ajax calls, these template portions end up being stored in separate template
snippet files and then {% include(d) %} in the main template. I think that
keeping everything related to a view in a single template file is much more
desirable. Therefore, just include part=selector in order to pull out the
part of the template that is needed for rendering. The file structure for
managing templates would become much simpler with this approach.
render_to_string(template_name, part=None, context=None, request=None,
using=None)
¶
render_to_string() loads a template like
get_template() and calls its render() method immediately.
It takes the following arguments.
template_name
The name of the template to load and render. If it’s a list of template
names, Django uses
select_template() instead of
get_template() to find the template.
part
An optional CSS selector that will be used to cause only the portion of the
template that matches the selector to be rendered.
context
A dict to be used as
the template’s context for rendering.
request
An optional
HttpRequest that will be available during the template’s rendering
process.
using
An optional template engine
NAME. The search for the template will be restricted to that engine.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/1c8201d898aa%240449fe50%240cddfaf0%24%40shenberger.org.
Re: Feature Request: New parameter for render_to_string() to render part of a template using a selector
Carlton Gibson has addressed my feature
request: https://github.com/carltongibson/django-template-partials
On Friday, July 15, 2022 at 8:21:52 PM UTC-4 Dan Swain wrote:
> With the growing uptake of technologies like HTMX, I would like to see an
> additional parameter added to render_to_string(). In my rewritten
> definition of render_to_string() below (taken from the docs), I have named
> the parameter “part”. In rendering portions of a template for responses to
> ajax calls, these template portions end up being stored in separate
> template snippet files and then {% include(d) %} in the main template. I
> think that keeping everything related to a view in a single template file
> is much more desirable. Therefore, just include *part=selector* in order
> to pull out the part of the template that is needed for rendering. The
> file structure for managing templates would become much simpler with this
> approach.
>
>
>
> *render_to_string**(**template_name**, part=None, **context=None**, *
> *request=None**, **using=None**)¶
> <https://docs.djangoproject.com/en/4.0/topics/templates/#django.template.loader.render_to_string>*
>
> *render_to_string()* loads a template like *get_template()*
> <https://docs.djangoproject.com/en/4.0/topics/templates/#django.template.loader.get_template>
> and
> calls its *render()* method immediately. It takes the following arguments.
>
> *template_name*
>
> The name of the template to load and render. If it’s a list of template
> names, Django uses *select_template()*
> <https://docs.djangoproject.com/en/4.0/topics/templates/#django.template.loader.select_template>
> instead
> of *get_template()*
> <https://docs.djangoproject.com/en/4.0/topics/templates/#django.template.loader.get_template>
> to
> find the template.
>
> *part*
>
> An optional CSS selector that will be used to cause only the portion of
> the template that matches the selector to be rendered.
>
> *context*
>
> A *dict* <https://docs.python.org/3/library/stdtypes.html#dict> to be
> used as the template’s context for rendering.
>
> *request*
>
> An optional *HttpRequest*
> <https://docs.djangoproject.com/en/4.0/ref/request-response/#django.http.HttpRequest>
> that
> will be available during the template’s rendering process.
>
> *using*
>
> An optional template engine *NAME*
> <https://docs.djangoproject.com/en/4.0/ref/settings/#std-setting-TEMPLATES-NAME>.
>
> The search for the template will be restricted to that engine.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/4d54fc0c-51b3-4dfd-9600-65552c338fcen%40googlegroups.com.
Configuration of "level" in LOGGING
The current Django LOGGING setup requires a string for the "level". This is
not intuitive since the Python logging module defines logging.DEBUG,
logging.INFO, etc. I think one should be able to configure the logging
level using { 'level': logging.DEBUG } rather than being required to use
{ 'level': 'DEBUG' }.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/010b01d8487b%24683216c0%2438964440%24%40shenberger.org.
