Working towards a simpler GCBV implementation?

[Tom Christie]

Hi folks,

I recently released an alternative implementation of Django's existing class based views.  The intention was to mirror the *exact* same set of functionality that we currently provide, but simplify the implementation and API.  It's nothing cleverer or grander than a clean re-write, but the end result is *significantly* less complex.  The class hierarchy is trivial, the API is much smaller, and the flow control is much more obvious.

I won't go into any more here, as there's plenty of detail in the documentation:

http://django-vanilla-views.org

There's also useful context in the related blog post, here:

http://dabapps.com/blog/fixing-djangos-generic-class-based-views/

The difficult thing here really is that there's no obvious approach to introducing something like this in a backwards compatible way.

It might be that we could take an incremental approach using the standard deprecation process, but given the nature of the GCBVs it'd likely be pretty awkward.

There might be some bits of deprecation process we simply wouldn't be able to deal with in any sensible way, and we'd certainly end up with a seriously gnarly implementation during the deprecation period.

I'd be interested in getting some opinions from folks on the following:

* If a simpler GCBV implementation along the lines of django-vanilla-views is something we think we should working towards.

* What approaches we might be able to take to dealing with backwards compatibility if we did want to do so.

Thanks for your time.

  Tom

[Yo-Yo Ma]

I'm excited about Django Vanilla Views. I think the GCBV implementation in Django is pretty good (I use GCBV got everything - leads to better extensibility), but a simpler version of the same functionality would be great. I'm NEVER certain of whether I'm using the right mixins and base class combos, or if I have them in the right inheritance order, or which share the same function, etc.

[Tino de Bruijn]

On Thu, Oct 3, 2013 at 11:09 AM, Tom Christie <christ...@gmail.com> wrote:

* If a simpler GCBV implementation along the lines of django-vanilla-views is something we think we should working towards.

Hells yes, +1. I love CBV, but when it gets a little more complex, I get dazzled.

 

* What approaches we might be able to take to dealing with backwards compatibility if we did want to do so.

Hmm,  from django.new_views import ..., like was done with new_forms?

[Albert O'Connor]

+1 to anything which makes CBV easier to use and simpler to understand.

From looking at what have done you have been able to address my biggest concern, the depth of the hierarchy. I find using flat "CBV" like the syndication framework a lot easier then the current GCBV implementation.

Thanks,

Albert O'Connor

--
You received this message because you are subscribed to the Google Groups "Django developers" 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/CANQFsQCg7zVkjvRM4M6MdvhtmkBMqyp-FhAr12yjFF57nJY0Yw%40mail.gmail.com.

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

--

><><><>< Albert O'Connor - amjo...@gmail.com
albertoconnor.ca | watpy.ca | go-opendata.ca

[James Pic]

I should state that I have no education and that I have the feeling
that I understand GCBVs perfectly.

But django-vanilla-views are not as usable because you cannot reuse
isolated pieces of functionality like you can with mixins.

Maybe this is a documentation problem ?

Maybe the docs should explicitly recommend to read the source code ?

Maybe it should recommend some links for users to sharpen their
understanding of GCBVs ?

Hope this helps

James

--
http://yourlabs.org

[Tom Christie]

> But django-vanilla-views are not as usable because you cannot reuse isolated pieces of functionality like you can with mixins.

The reusable components that it gives you are `GenericView` and `GenericModelView`.

Generally they're going to be the baseline that you'd want to work with anyways.

As one example of reusing these base components I've refactored Andrew Ingram's `django-extra-views` package using vanilla views. (*)

The end result is a set of generic views for dealing with formsets that came out something like 2/3 as much code as was previously required, and again, with a much simpler more obvious implementation throughout.

> from django.new_views import ..., like was done with new_forms?

Okay, so there's a precedent.

Really I'm still trying to sound out where the community stands on this.

If there was a pull request along these lines should I expect it to get rejected out of hand as too much of a radical change, or are folks sufficiently convinced that this is a good idea?

Thanks,

  Tom

(*): See https://github.com/tomchristie/django-extra-views - Not properly doc'ed or packaged yet, but considering doing so and releasing as a `django-vanilla-formsets` package.

[Asif Saifuddin]

Hi Tom,

I am basically +1 to see this change in the django core. The package is 3 years old and should be tested enough. If you/other core team members thinks that now is a good time to include it to core and deprecation of older API, then I will be willing to work and send PR for this.

Looking for others opinions.

Thanks,

Asif

[Asif Saifuddin]

Hi,

I have started work on https://github.com/django/django/pull/7783 for converting django built in generic views to django-vanilla-views.

I would like to hear what you think before I proceed for more.

Thanks,

Asif

[Adam Johnson]

I think this is probably too disruptive a change for Django core, especially after so long with the current GCBV implementations - it would require all users to rewrite their CBV's. Possibly the documentation could recommend django-vanilla-views?

--
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-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5792872e-157c-4ba6-87c1-bf0f5a07d981%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Adam

[Asif Saifuddin]

Hi,

I will update the doc pointing vanilla views as simpler alternative implementation.

Thanks

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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5792872e-157c-4ba6-87c1-bf0f5a07d981%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Adam

[Tim Graham]

We typically shy away from endorsing third-party libraries in the Django docs. I don't think it makes much sense to stay something to the effect of "The built-in views are too complex so we recommend using other library instead."

[Adam Johnson]

Fair enough, there are other community resources for this.

The PR adding a pointer in the docs to ccbv.co.uk in https://github.com/django/django/pull/7785 is a good idea that came from this thread though.

To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/99823816-8352-40ba-99b7-bfe5006424a0%40googlegroups.com.

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

--

Adam

[Alex Scott]

If most everyone agrees that Tom's Vanilla Views are superior than what's currently in core, maybe the path forward is to integrate into 2.0?

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/99823816-8352-40ba-99b7-bfe5006424a0%40googlegroups.com.

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

--

Adam

[Florian Apolloner]

On Friday, January 6, 2017 at 11:11:37 AM UTC+1, Alex Scott wrote:

If most everyone agrees that Tom's Vanilla Views are superior than what's currently in core, maybe the path forward is to integrate into 2.0?

2.0 is not going to be as backwards incompatible as you might, it is mainly 2.0 because we drop py2.

[Sayid Munawar]

+1 to use vanilla-views in django 2.0

every time i write some view, i always open https://ccbv.co.uk/ in another tabs :D and trying to figure out where should i make my overrides 

[James Bennett]

Please read Florian's message. 2.0 is not going to be "we bumped the major version, now we can pile in lots of breaking changes".

[Asif Saif Uddin]

IMHO, we can include vanilna views like simpler implementations for GCBV and may be ViewSets As well. extensively document the old iplementations to newer implementations, and not deprecating the current implementations that early. they way django regex_based url was converted to sipler path() based url routing, that could be a good path for this.

Best,

Asif

[Asif Saif Uddin]

all good new things were disruptive in django no matter what. urls and paths existed but the newer approach were recommended for new projects. the current GCBV are not so simple.

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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5792872e-157c-4ba6-87c1-bf0f5a07d981%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Adam