Discuss https://github.com/django/django/pull/11157

[Petr Glotov]

Hi All, there is a PR where template streaming is introduced, and recently a discussion emerged on wether a StreamingTemplateView class belongs in Django. I know for sure I'd be glad to replace TemlateView based views in one of project I'm working on with the proposed StreamingTemplateView and be done with it. The alternative point of view is that it would take a user an extra step of making a decision ("decision point") of (i guess) choosing between TemplateView and StreamingTemplateView, so the suggestion is to remove StreamingTemplateView. So I would like to ask people to chime in. Thanks!

[Carlton Gibson]

It's not really a recent discussion. 🙂

The original mailing list thread here was from 2015: 

https://groups.google.com/d/topic/django-developers/kuGeu7ffJsc/discussion

I based my comments on the PR on a review + Aymeric and Tom's previous reviews there, which were never acted on. 

I quoted Tom on the PR but, as I said there, his and Aymeric's points are well worth reviewing in full. 

Here's a particular extract from Aymeric: 

> I set a bad precedent when I added StreamingHttpResponse. I didn't think of HttpResponse(stream=True) at the time. The prospect of having 25 StreamingFooBar classes in Django makes me realize this wasn't a great idea. Let's learn from this mistake. 

[Adam Johnson]

I've had a quick look at the PR and discussions. The ability to stream template rendering looks fantastic and I know I've seen on a few features in projects that could take advantage of it.

I agree with Carlton's last comment on the PR though.  Adding all the extra classes to Django is a bit of a combinatorial explosion, and most of the code saves just a couple lines of code for the user. Normally we are conservative on adding extra stuff to Django: we want to support it until the heat death of the universe, the termination of the internet, or its deprecation (whichever comes first).

Thank you for your work on this long-standing ticket and I hope we can get it merged in time for Django 3.0's feature freeze!

--
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-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/754f4f5b-6257-49d4-bfd1-98fbf9b0738c%40googlegroups.com.

--

Adam

[Petr Glotov]

What if we keep  StreamingTemplateResponse and do TemplateView(stream=True) flag?

I just want to have something out of the box to use.

[Carlton Gibson]

I’m exactly -1 on this, for exactly the reasons given.   ALL it takes for you to implement this is to subclass TemplateView and override render_to_response(). That’s it. 

This was Tom’s point in his review four years ago: the ease of directly implementing it means the added API surface area isn’t worth it. 

--

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-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/86877d7b-94ba-4ab7-9bcc-e2f39eab8578%40googlegroups.com.

[Petr Glotov]

Overriding render_to_response() would take creating an instance of StreamingHttpResponse with streaming_content kwarg using self.resolve_template(), self.resolve_content() and applying self.make_bytes() to it? It's possible but as a user i'd rather not need to know how Django's TemplateView operates under the hood. It's like if an automaker coming up with a new engine but refusing to make a car with it and instead selling the engine itself suggesting people to build cars themselves.

Still, what if we implement TemplateView(stream=True)which would do it internally? We don't have to expose StreamingTemplateResponse.

On Saturday, July 20, 2019 at 5:22:37 AM UTC-7, Carlton Gibson wrote:

I’m exactly -1 on this, for exactly the reasons given.   ALL it takes for you to implement this is to subclass TemplateView and override render_to_response(). That’s it. 

This was Tom’s point in his review four years ago: the ease of directly implementing it means the added API surface area isn’t worth it. 

On Sat, 20 Jul 2019 at 13:31, Petr Glotov <pegl...@gmail.com> wrote:

What if we keep  StreamingTemplateResponse and do TemplateView(stream=True) flag?

I just want to have something out of the box to use.

On Friday, July 19, 2019 at 5:40:52 PM UTC-7, Petr Glotov wrote:

Hi All, there is a PR where template streaming is introduced, and recently a discussion emerged on wether a StreamingTemplateView class belongs in Django. I know for sure I'd be glad to replace TemlateView based views in one of project I'm working on with the proposed StreamingTemplateView and be done with it. The alternative point of view is that it would take a user an extra step of making a decision ("decision point") of (i guess) choosing between TemplateView and StreamingTemplateView, so the suggestion is to remove StreamingTemplateView. So I would like to ask people to chime in. Thanks!

--
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-d...@googlegroups.com.