2015-12-22 18:34 GMT+01:00 Marc Tamlyn :
> I'd be in favour of just undocumenting it for now.
>
I would be fine with either keeping it in the docs with a "you probably
want render() instead" note or removing it from the docs. Then in a few
years we can deprecate it.
--
Aymeric.
--
You receive
Personally, I find that decorators aren't the best way of interacting with
CBVs. They're useful when you have a mixed style codebase, but I tend to
convert the decorator into a mixin applied at the appropriate point. I
think the style of decorating in the URLconf is horrible.
Marc
On 21 December
I'd be in favour of just undocumenting it for now.
On 22 December 2015 at 16:27, Alasdair Nicol wrote:
> I think that updating the docs to use render instead of render_to_response
> is an good change. Many of the CSRF problems that I see new users
> struggling with are solved simply by switching
I think that updating the docs to use render instead of render_to_response
is an good change. Many of the CSRF problems that I see new users
struggling with are solved simply by switching to render.
Since passing context_instance to render_to_response is deprecated in 1.8.
If I understand corre
In 2010/Django 1.3 when the render() shortcut was introduced Jacob
proposed: "I think we should deprecate render_to_response() in favor of
render(). render_to_response() is just render(request=None, ...), right?
Any reason to keep both around?"
Russ replied: "There's no particular reason to kee
