About Class Based views

[Asif Saifuddin]

Hi,

I found this blog post about class based views of django

http://lukeplant.me.uk/blog/posts/my-approach-to-class-based-views/

what do you guys think about?

Regards

[Gaurav Dadhania]

IMHO, Class-based views — either ones provided by Django or a 3rd party library or your own —  are an inheritance pattern, like any other design pattern, use it if it suits your use case. Like a lot of things, there is no one, right answer. 

I've enjoyed using CBVs for CMS-y projects (list products, product detail, product edit OR list posts, post detail, post edit, etc.) and functional views for endpoints which don't really have much in common eg: payment processing, authentication/authorization endpoints, etc. (use decorators for common simple guard checks, rate limiting, response serialization/template rendering if you need). YMMV. 

Cheers,

G

--
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 post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e84fd370-044e-456e-b2f3-fd028f41232e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paulo Gabriel Poiati]

The problem with CBV is the learning curve. You can do standard things like CRUD's fast as hell but if you need some kind of customisation you probably gonna need to deep dive into the class hierarchy to understand it. If you dominate it you will be very productive and happy.

I'm not saying there isn't room for improvement, there is and this blog post is showing some of them.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHgJS%3D_OCgApx6SBdqYCQysLU6MFR%3DganAwYv7LNBE4gzzucaA%40mail.gmail.com.

[Moritz S.]

Am Dienstag, 17. März 2015 20:41:53 UTC+1 schrieb poiati:

The problem with CBV is the learning curve. 

Totally agree with that!

Personally I really like CBVs and I also write my own subclasses and mixins regularly, but I think you'll really have a hard time even writing a simple mixin if you have never heard of mro or metaclasses.

[Curtis Maloney]

I found when taking the CBGV session in MelbDjango School, it was best to approach teaching CBV as an exercise in Interfaces.

Once the students were familiar with writing basic views, and the patterns therein, much of CBGV became "obvious", and the lesson focused more on the power of interfaces.

As I've said many times on IRC I'd love a site that shows the layers of interfaces in various CBGV so it becomes clearer how they interact.  Unfortunately, I don't have the time or skills to pull this off :/

--

C

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/19d912c9-3dc2-4a13-a4bd-e2f0354e95b1%40googlegroups.com.

[Russell Keith-Magee]

On Wed, Mar 18, 2015 at 5:38 AM, Curtis Maloney <cur...@acommoncreative.com> wrote:

I found when taking the CBGV session in MelbDjango School, it was best to approach teaching CBV as an exercise in Interfaces.

Once the students were familiar with writing basic views, and the patterns therein, much of CBGV became "obvious", and the lesson focused more on the power of interfaces.

As I've said many times on IRC I'd love a site that shows the layers of interfaces in various CBGV so it becomes clearer how they interact.  Unfortunately, I don't have the time or skills to pull this off :/

You mean something like:

http://ccbv.co.uk

or did you have something else in mind?

Yours,

Russ Magee %-)

[Curtis Maloney]

No... I'm well aware of CCBV, and think it's a great tool... however, I had in mind something that would more clearly show (a) the stratified layers of interface, and (b) the typical call paths [through the layers] of the various Views and Mixins.

Such a visualisation, I feel, would help many people more readily grasp how all the pieces fit together, and where to hook in to get the results they want.

--

C

--

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 post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq848-7%3D%2BL_foUTvkH3rDw1n_c-zDbpqUtkHdVA0wKJbY3_w%40mail.gmail.com.

[Ryan Hiebert]

As a anecdotal data point, when I getting started with class-based views I put everything into get_context_data method, because that’s where I thought the code for constructing the context should go. I eventually figured out that I should probably never override that method, but rather override get() or post(), etc, and _call_ it with the context I desired.

Having some better documentation of what the Right Way to subclass these views would have been a great help. The fact that the documentation is fragmented because of the mixin inheritance definitely makes understanding how to use those generic class based views more challenging.

I’m not sure what magical visualization would make the proper override methods obvious, but if there was one, I think it would definitely have helped me grok how to use class-based views effectively.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAG_XiSBb3iT9RXS87HHY2WJekR53LuDbTpCZ_sW3%3DhmyRA-sTA%40mail.gmail.com.