Description

I think there is a common need to use reuse logic-backed data in multiple places (e.g. latest comments box in a blogging app)

While ​RequestContexts may work in ​some cases , it may not be the right-by-design solution for a bit more complex ones.

A well-known solution among django community is use of templatetags: (e.g. ​QA1, ​QA2)
But regarding the NIH-syndrome I don't think it would be a good idea to invent yet-another-templatetag for each embedded view, which I've already seen it in many projects.

I suppose having a render_view templatetag in core would both increase code reuse and readability. See ​Symfony2 for an equivalent approach.

The implementation would be pretty straightforward, with a new simple_tag forwarding calls to appropriate view. A bonus would be the ability provide ajax-based partial contents.

Django views take an HTTP request and return an HTTP response. A full HTTP response, including status code and headers, not a snippet of rendered HTML to fill in part of a complete response. Since views return full HTTP responses I don't see how a render_view template tag can make sense; you cannot embed a full HTTP response as part of a template you are rendering. If you want to do advanced processing of some sort in a re-usable way in your application, the way to do that is with a custom template tag.

What about ajax views? Think of the render_view using only ajax-natured views: those returning partial content.

Let's rephrase that, if "view" doesn't make enough sense, and use "function" instead of "view".

What I'm seeing as an anti-pattern, is the pretty-much-same code being duplicated under different tag names in different projects. And I'd say the "right" way is not that hard: Have a simple function/view/whatever-suits renderer tag!

An ajax view still returns a complete HTTP response. And I'm confused as to how you would want that rendered in a template. If you want a tag that renders a (sub)-template, that's called an inclusion tag (​https://docs.djangoproject.com/en/1.5/howto/custom-template-tags/#inclusion-tags). Without specifics I have no idea what you are referring to when you say you see an anti-pattern of pretty much the same code duplicated under different names in different project, nor how some sort of "render it" tag would fix that. Possibly you should take this discussion to the django-developers mailing list to get feedback from others; I'm sorry but what you are asking for here isn't making sense to me.