Re: Working towards a simpler GCBV implementation?

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. On Tuesday, January 3, 2017 at 7:20:24 PM UTC+6 Adam Johnson wrote: > I think this is probably too disruptive a

Re: Working towards a simpler GCBV implementation?

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()

Re: Working towards a simpler GCBV implementation?

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". -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this

Re: Working towards a simpler GCBV implementation?

+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 On Friday, January 6, 2017 at 5:11:37 PM UTC+7, Alex Scott wrote: > > If most everyone agrees that Tom's Vanilla

Re: Working towards a simpler GCBV implementation?

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

Re: Working towards a simpler GCBV implementation?

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? On Wednesday, January 4, 2017 at 3:00:03 PM UTC-5, Adam Johnson wrote: > > Fair enough, there are other community resources for this. > > The PR adding a

Re: Working towards a simpler GCBV implementation?

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. On 4 January 2017 at 13:08, Tim Graham wrote: > We typically shy

Re: Working towards a simpler GCBV implementation?

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." On Wednesday, January 4, 2017 at 7:30:54 AM UTC-5, Asif

Re: Working towards a simpler GCBV implementation?

Hi, I will update the doc pointing vanilla views as simpler alternative implementation. Thanks On Tuesday, January 3, 2017 at 7:20:24 PM UTC+6, Adam Johnson wrote: > > I think this is probably too disruptive a change for Django core, > especially after so long with the current GCBV

Re: Working towards a simpler GCBV implementation?

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? On 3 January 2017 at 13:02, Asif Saifuddin

Re: Working towards a simpler GCBV implementation?

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 On Friday, September 16, 2016 at 1:37:36 AM UTC+6, Asif Saifuddin wrote: > >

Re: Working towards a simpler GCBV implementation?

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.

Re: Working towards a simpler GCBV implementation?

> 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.

Re: Working towards a simpler GCBV implementation?

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

Re: Working towards a simpler GCBV implementation?

+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,

Re: Working towards a simpler GCBV implementation?

On Thu, Oct 3, 2013 at 11:09 AM, Tom Christie 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. > *

Working towards a simpler GCBV implementation?

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

Working towards a simpler GCBV implementation?

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,