Quantcast

What was the rationale behind ClassBasedView.as_view()

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

What was the rationale behind ClassBasedView.as_view()

Frederik Creemers
Django views are just functions that take a request, and possibly some other args, and return a response. To get such a view from a class based view, you can  `as_view()` on it. Why is that? Wouldn't it make the code neater to just implement `__call__` on the views? What was the reing behind having `as_view`?

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/9b30675a-0f21-498e-a507-c6130e5eafaf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What was the rationale behind ClassBasedView.as_view()

Daniel Roseman-2
On Monday, 13 March 2017 18:36:46 UTC, Frederik Creemers wrote:
Django views are just functions that take a request, and possibly some other args, and return a response. To get such a view from a class based view, you can  `as_view()` on it. Why is that? Wouldn't it make the code neater to just implement `__call__` on the views? What was the reing behind having `as_view`?

A search in django-developers would probably reveal the extremely long-running thread that led to that specific implementation.

But, briefly, allowing the CBVs to be instantiated in the URLs would render them non-thread safe. Any attribute set on the object would persist across all future requests, leading to information leakage and other very bad behaviour. The `as_view()` construct is a (mostly successful) effort to make it almost impossible to break the thread safety of the view objects.
--
DR.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1b6323e5-ca93-4ccf-91d5-da7d5a72f6b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What was the rationale behind ClassBasedView.as_view()

Frederik Creemers
That makes heaps of sense, thanks!

On Mon, Mar 13, 2017 at 10:49 PM Daniel Roseman <[hidden email]> wrote:
On Monday, 13 March 2017 18:36:46 UTC, Frederik Creemers wrote:
Django views are just functions that take a request, and possibly some other args, and return a response. To get such a view from a class based view, you can  `as_view()` on it. Why is that? Wouldn't it make the code neater to just implement `__call__` on the views? What was the reing behind having `as_view`?

A search in django-developers would probably reveal the extremely long-running thread that led to that specific implementation.

But, briefly, allowing the CBVs to be instantiated in the URLs would render them non-thread safe. Any attribute set on the object would persist across all future requests, leading to information leakage and other very bad behaviour. The `as_view()` construct is a (mostly successful) effort to make it almost impossible to break the thread safety of the view objects.
--
DR.

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/ih8_zwLQVgc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1b6323e5-ca93-4ccf-91d5-da7d5a72f6b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJA%3DsDTY_m3PkYPeL5pW-gyB%2BcC__HJvRf1_iEPBD1nBd3%2BuAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: What was the rationale behind ClassBasedView.as_view()

Russell Keith-Magee-4
There’s also a summary of the various options that were considered:


Yours,
Russ Magee %-)

On Tue, Mar 14, 2017 at 10:08 AM, Frederik Creemers <[hidden email]> wrote:
That makes heaps of sense, thanks!

On Mon, Mar 13, 2017 at 10:49 PM Daniel Roseman <[hidden email]> wrote:
On Monday, 13 March 2017 18:36:46 UTC, Frederik Creemers wrote:
Django views are just functions that take a request, and possibly some other args, and return a response. To get such a view from a class based view, you can  `as_view()` on it. Why is that? Wouldn't it make the code neater to just implement `__call__` on the views? What was the reing behind having `as_view`?

A search in django-developers would probably reveal the extremely long-running thread that led to that specific implementation.

But, briefly, allowing the CBVs to be instantiated in the URLs would render them non-thread safe. Any attribute set on the object would persist across all future requests, leading to information leakage and other very bad behaviour. The `as_view()` construct is a (mostly successful) effort to make it almost impossible to break the thread safety of the view objects.
--
DR.

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/ih8_zwLQVgc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1b6323e5-ca93-4ccf-91d5-da7d5a72f6b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJA%3DsDTY_m3PkYPeL5pW-gyB%2BcC__HJvRf1_iEPBD1nBd3%2BuAg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJxq84-wjL2Vdd5dEGtgxhB%2BwvG0Maarr%3DjuM9qC58MZEdY87g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Loading...