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 <[email protected] <javascript:>> > 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 <https://github.com/django/django/pull/11157> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/86877d7b-94ba-4ab7-9bcc-e2f39eab8578%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/86877d7b-94ba-4ab7-9bcc-e2f39eab8578%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1d962796-092c-41c7-8766-bcf21b7cfe7f%40googlegroups.com.
