Don't you have to render the template in the first place if you want to
extract a fragment of it? If that's the case then shouldn't
render_to_string be left unchanged and libraries interested in this feature
build something on top of it to achieve what they're after?
Given render_to_string is content type agnostic (I've seen it used to
generate text, markdown, ...) and that safely dealing with CSS selectors
and HTML parsing server side is large problem by itself I'm -1 on adding
this feature as I don't see a compelling reason why this should be added to
core.
I think you'd be much better served by a template backend that allows for
developer defined logical sections of templates (e.g. {% block %} like )
to be targeted for isolated rendering through provided context instead of a
fully fledged HTML/CSS based solution that strips unused bytes from a fully
rendered template. To me your proposed solution trades a lot of resources
(HTML parsing, CSS selector sanitization and execution) for a promise of
network usage reduction.
Cheers,
Simon
Le vendredi 15 juillet 2022 à 20:21:52 UTC-4, Dan Swain a écrit :
> 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/277490ed-0606-4aa1-982d-e2fb342201bcn%40googlegroups.com.
