> If I figured out correctly the class based generic views does not land
> on 1.2, so I was wondering are they planned to 1.3? Those are rather
> important after all...

> [1] http://github.com/jacobian/django/tree/class-based-generic-views/djan...

> On 11 touko, 03:37, Russell Keith-Magee <russ...@keith-magee.com>
> wrote:
>> show us the code!.

>> [1] http://github.com/jacobian/django/tree/class-based-generic-views/djan...

> Yes, well. I have been in slight assumption that the above code is the
> one that will be merged. Though if it needs to be improved, I think
> Jacobian could *list the problems in his implementation* so others can
> try to improve on them, as he probably knows that code best.

> From that point of view, I don't see a reason in rewriting the class
> based generic-views as there is already Jacobian's take on it.

> Are class-based views planned for 1.3? Well, we haven't done any
> formal planning for 1.3 yet, but I'm going to guess that the 1.3 high
> priority feature list will essentially be "the features that got
> dropped from 1.2", so in all likelihood, yes. However, that doesn't
> mean that they will definitely be in 1.3 - someone still needs to do
> the implementation. If you really want class based generic views, be
> like Ben and make it happen -- show us the code!.

> > Are class-based views planned for 1.3? Well, we haven't done any
> > formal planning for 1.3 yet, but I'm going to guess that the 1.3 high
> > priority feature list will essentially be "the features that got
> > dropped from 1.2", so in all likelihood, yes. However, that doesn't
> > mean that they will definitely be in 1.3 - someone still needs to do
> > the implementation. If you really want class based generic views, be
> > like Ben and make it happen -- show us the code!.

> Oooh, class-based views.

> This is something I've been thinking about a lot, and I'll probably dive into it at the Djangocon.eu sprints. Feel free to make a start Jari. ;)

> Ben

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.

> On 11 May 2010, at 01:37, Russell Keith-Magee wrote:

>> Are class-based views planned for 1.3? Well, we haven't done any
>> formal planning for 1.3 yet, but I'm going to guess that the 1.3 high
>> priority feature list will essentially be "the features that got
>> dropped from 1.2", so in all likelihood, yes. However, that doesn't
>> mean that they will definitely be in 1.3 - someone still needs to do
>> the implementation. If you really want class based generic views, be
>> like Ben and make it happen -- show us the code!.

> Oooh, class-based views.

> This is something I've been thinking about a lot, and I'll probably dive into it at the Djangocon.eu sprints. Feel free to make a start Jari. ;)

> > * How to decorate the __call__ method without doing a pointless
> > override of __call__ that just calls super so that you have
> > something to @decorate on top of. Check out the meta class on line
> > 175. This allows you to specify 'decorators = [login_required,
> > permission_required("polls.can_vote")]' on your subclass. I showed
> > this to Jacob at DjangoSki, and he seemed positive.

> I personally don't like metaclasses if we can find another way.  Here
> are some alternatives which use Plain Old Python:

> 1) from Python 2.6 we could use class decorators, and we could use the
> 'old style' MyClass = some_class_decorator(MyClass) until we move to
> Python 2.6.

> 2)
>   class Foo(View):
>      __call__ = some_decorator(View.__call__)

> 3) Add the decorators when you call 'instantiator' (which, by the way,
> I would rather call 'make_view' or something more specific).  You
> would then have, *in views.py*:

> 3a) my_view = some_decorator(make_view(MyViewClass))

> or possibly (though I don't think this adds much):

> 3b) my_view = make_view(MyViewClass,
>                        decorators=[some_decorator])

> This has some significant advantages:

>  - you don't need to worry about method decorators

>  - you can re-use MyViewClass with different decorators

>  - it protects us from changing the URLconf.  The URLconf always
>   has a reference to the 'my_view' function, rather than
>   MyViewClass.  Class-based views then remain an implementation
>   detail, just as they ought to be.  It may well be that
>   a re-usable app provides some views and might switch
>   from class-based views to normal functions, and URLconfs
>   should be insulated from that change.

> I don't like the idea of special-casing class based views anywhere,
> whether to cope with state or anything else.  I think a view should
> still be 'a callable that takes a request and returns a response'.  If
> that means we have to add an extra line to create a view function from
> a view class, so be it.

> Given that it is going to be possible to use any/all of these whatever
> Django provides, I think I'm quite strongly in favour of 3a), and
> opposed to adding a metaclass which really doesn't add anything
> significant.  Metaclasses add complications for people attempting to
> understand code, and should be used only when you really need them.

> > * How to decorate methods, when the decorator expects the first
> > argument to be request, and not self. See line 8. Ideally though,
> > Django's decorators would handle this, rather than forcing the use
> > of decorate_method_with on to the end users.

> We already have 'django.utils.decorators.method_decorator' to cope
> with this.  All attempts to have decorators that automatically adapt
> to functions/methods have failed.  See my message here
> http://groups.google.com/group/django-developers/msg/f36976f5cfbcbeb3
> It has some attachments with test cases that show how our previous
> attempt to do this didn't work in some situations.

> One thing we could do to make it nicer for the end user is to create
> our own 'method' versions of all supplied decorators i.e:

>  cache_page_m = method_decorator(cache_page)

> for every decorator we provide, so that people don't need to do that
> themselves.

> However, this point may be moot given the discussion above.

> Luke

> --
> "Mistakes: It could be that the purpose of your life is only to
> serve as a warning to others." (despair.com)

> Luke Plant || http://lukeplant.me.uk/

> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscribe@googlegroups.com<django-developers%2Bunsubscr ibe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.

> This is something I've been thinking about a lot, and I'll probably dive into it at the Djangocon.eu sprints.

> > I'm used to Plone sprints and there's usually some "make sure you have svn
> > access to x and y" stuff best handled *before* the sprint, that's why I'm
> > asking :-)

> This might help:http://code.djangoproject.com/wiki/Sprints

> If you have questions after that, let me know -- I'd be happy to
> improve that page.

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.

> This might help:
> http://code.djangoproject.com/wiki/Sprints

> So: is that just a missing piece of documentation? Or is the  
> virtualenv kind of isolation rarely done when developing on trunk?

> 3a) my_view = some_decorator(make_view(MyViewClass))

> or possibly (though I don't think this adds much):

> 3b) my_view = make_view(MyViewClass,
>                         decorators=[some_decorator])

> We're working on this with Ben during djangocon.eu sprint [1]. Any
> comment appreciated, still a work in progress though.

>> We're working on this with Ben during djangocon.eu sprint [1]. Any
>> comment appreciated, still a work in progress though.

> Looks cool.  I think Jari's idea of a class method to instantiate the
> classes would be a great pattern to establish - something like an
> 'as_view' classmethod on the base class which returns a view function
> that uses the class:

>    @classmethod
>    def as_view(cls, *initargs, **initkwargs):
>        def view(*args, **kwargs):
>            obj = cls(*initargs, **initkwargs)
>            return obj(*args, **kwargs)
>        return view

> The developer can choose whether to write 'MyClassView.as_view()'
> directly into the URLconf, or put a line into views.py like 'my_view =
> MyClassView.as_view()'

> This will solve the thread safety issue, and doesn't require another
> import for a decorator, as Jari pointed out.

> We could decide whether to apply decorators inside as_view() or  
> __call__().  The argument for putting it in 'as_view' is that __call__
> does some processing that you might want to skip entirely (e.g. the
> get_object() call - if we applied a 'cache_page' decorator, we
> wouldn't want the get_object() call to be made at all if there was a
> cache hit).

> On that point, I think 'GenericView' should be split into 'ClassView'
> and 'GenericView'.  The get_object() call is probably not a good thing
> to have on a base class.

> > We could decide whether to apply decorators inside as_view() or
> > __call__().  The argument for putting it in 'as_view' is that
> > __call__ does some processing that you might want to skip
> > entirely (e.g. the get_object() call - if we applied a
> > 'cache_page' decorator, we wouldn't want the get_object() call
> > to be made at all if there was a cache hit).

> We discussed that point with Jacob and it looks like it's easier to
> modify urlresolvers to create a new instance of the class when we
> detect it's a class, this should solve the thread safety issue. Do
> you see any drawback to this approach?

> We're currently working towards URLpatterns of the form::

>    ('...', SomeView)

> i.e. passing a class directly, which would be instantiated implicitly
> then called.

> The reason we're trying it this way is thread safety: if a view is a
> class, then people *will* store state on self. So if we have single
> instances in views like we do now, then we're giving folks enough rope
> to hang themselves. By having each request get a fresh instance we
> avoid that problem.

> The other alternative we discussed was having the base view class do
> something with threadlocals to make sure state saved on self is
> threadsafe. I vetoed that because I hate threadlocals :)

> On Fri, May 28, 2010 at 3:41 PM, Luke Plant <L.Plant...@cantab.net> wrote:
>> I'm sure that will work.  My main reluctance is using isinstance()
>> when it isn't necessary, and having to change the definition of what a
>> 'view' is when it isn't strictly necessary. (A view is no longer
>> simply "a callable that takes a request and returns a response").

> I *am* a bit worried by this -- I'm not sure redefining the definition
> of "view" is such a good idea. "A view is a callable or a class with
> callable instances" isn't nearly as simple and nice a recommendation.

>> If, however, we encouraged `MyClassView.as_view()` from the start, we
>> can cope with constructor arguments more easily - it changes to
>> `MyClassView.as_view(somearg=something)`.

> My only real objection here is that `as_view` is just a bunch of boilerplate::

>    urlpatterns = patterns('',
>        ('one/', SomeView.as_view()),
>        ('two/', SomeOtherView.as_view()),
>        ('three', YourView.as_view())
>    )

> I just really don't like the way that looks.

> As for accepting extra __init__ arguments: I specifically *don't* want
> to allow this (at least easily) because I want to encourage
> subclassing as the "correct" way of extending views. Yes, this means a
> slight loss of flexibility, but it also means that we're forcing
> people into a more extensible and fuure-proof way of coding, and
> that's a good thing.

>> (Either way, it would still be possible to pass in MyClassView() and
>> get thread safety problems, but it's about making mistakes less
>> natural).

> ... and either way it's pretty easy to issue a warning if you've
> subclassed ``django.views.View`` (my proposed name for the view base
> class) and re-used it for multiple requests.

>> There is also the issue of what to do when you need to add a decorator
>> to someone else's view function.

> Again, I want to encourge "subclass it" as the correct answer here.

>> Given that, for many Django apps, the view functions are part of the
>> public API that needs to be exported (i.e. hooked into people's
>> URLconfs or wrapped for re-use), I think it would be good to encourage
>> practices which will lead to stable and consistent APIs, and so *not*
>> allow or encourage classes to be used directly in the URLconf.

> I think we're in agreement here -- we're both trying to avoid view-ish
> stuff in the URLconfs (a la the old way we used to do generic views
> with dicts in urls.py).

> Having played with it for a few years now, though, I'm finding
> subclassing is really the best way to make this happen.

> So reusable apps instead of exporting functional views export
> class-based ones; users who want to re-use them import, subclass, and
> extend.

> Jacob

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

>     urlpatterns = patterns('',
>         ('one/', SomeView.as_view()),
>         ('two/', SomeOtherView.as_view()),
>         ('three', YourView.as_view())
>     )

> I just really don't like the way that looks.

> Again, I want to encourge "subclass it" as the correct answer here.

>> My only real objection here is that `as_view` is just a bunch of
>> boilerplate::

>>    urlpatterns = patterns('',
>>        ('one/', SomeView.as_view()),
>>        ('two/', SomeOtherView.as_view()),
>>        ('three', YourView.as_view())
>>    )

>> I just really don't like the way that looks.

> Agreed.  I also think that if you have a mixture of normal views and
> class based view, this is ugly:

>     urlpatterns = patterns('app.views',
>         ('one/', 'some_view_function',
>         ('two/', SomeOtherView),
>         ('three/', YourView)
>     )

> and it would be nicer to spell it:

>     urlpatterns = patterns('app.views',
>         ('one/', 'some_view_function'),
>         ('two/', 'some_other_view'),
>         ('three/', 'your_view')
>     )

> and have these additional lines in 'app.views':

>    some_other_view = SomeOtherView.as_view()
>    your_view = YourView.as_view()

> I know that is just moving the boilerplate around, but it is giving a
> consistent interface.  If some code in a re-usable app moves from
> normal views to class based views, they will have to do something like
> this *anyway* for backwards compatibility.

> But I can see that if subclassing is the default way of re-using, then
> exporting these functions gives multiple options about how they should
> be re-used, which you are wanting to avoid.

>>> There is also the issue of what to do when you need to add a
>>> decorator to someone else's view function.

>> Again, I want to encourge "subclass it" as the correct answer here.

> In that case, I guess it would be good to make this hard to do wrong,
> by providing helpers that add the decorator to the right end of the
> list of decorators.

> Regards,

> Luke

> --
> "Oh, look. I appear to be lying at the bottom of a very deep, dark
> hole. That seems a familiar concept. What does it remind me of? Ah,
> I remember. Life."  (Marvin the paranoid android)

> Luke Plant || http://lukeplant.me.uk/

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

> But don't worry, we've changed our minds again! If __call__() creates a copy of self and calls methods on the copy, as far as I can see it solves all our problems. No boilerplate, and it's really hard to make it unsafe thread-wise.

> An example of how it could work:

> http://github.com/bfirsh/django-class-based-views/blob/master/class_b...

> Thanks

> Ben

> On 29 May 2010, at 00:07, Luke Plant wrote:

> > On Friday 28 May 2010 15:51:32 Jacob Kaplan-Moss wrote:

> >> My only real objection here is that `as_view` is just a bunch of
> >> boilerplate::

> >>    urlpatterns = patterns('',
> >>        ('one/', SomeView.as_view()),
> >>        ('two/', SomeOtherView.as_view()),
> >>        ('three', YourView.as_view())
> >>    )

> >> I just really don't like the way that looks.

> > Agreed.  I also think that if you have a mixture of normal views and
> > class based view, this is ugly:

> >     urlpatterns = patterns('app.views',
> >         ('one/', 'some_view_function',
> >         ('two/', SomeOtherView),
> >         ('three/', YourView)
> >     )

> > and it would be nicer to spell it:

> >     urlpatterns = patterns('app.views',
> >         ('one/', 'some_view_function'),
> >         ('two/', 'some_other_view'),
> >         ('three/', 'your_view')
> >     )

> > and have these additional lines in 'app.views':

> >    some_other_view = SomeOtherView.as_view()
> >    your_view = YourView.as_view()

> > I know that is just moving the boilerplate around, but it is giving a
> > consistent interface.  If some code in a re-usable app moves from
> > normal views to class based views, they will have to do something like
> > this *anyway* for backwards compatibility.

> > But I can see that if subclassing is the default way of re-using, then
> > exporting these functions gives multiple options about how they should
> > be re-used, which you are wanting to avoid.

> >>> There is also the issue of what to do when you need to add a
> >>> decorator to someone else's view function.

> >> Again, I want to encourge "subclass it" as the correct answer here.

> > In that case, I guess it would be good to make this hard to do wrong,
> > by providing helpers that add the decorator to the right end of the
> > list of decorators.

> > Regards,

> > Luke

> > --
> > "Oh, look. I appear to be lying at the bottom of a very deep, dark
> > hole. That seems a familiar concept. What does it remind me of? Ah,
> > I remember. Life."  (Marvin the paranoid android)

> > Luke Plant ||http://lukeplant.me.uk/

> > --
> > You received this message because you are subscribed to the Google Groups "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.