Re: Class based generic views in 1.3?

[Nick Fitzgerald]

Luke,

Good points, especially about wrapping decorators *after* instantiation to
avoid the whole nasty self issue.

While I personally don't mind meta classes at all, I understand why some
people do.

I think you are probably on the right track here.

_Nick_

On Thu, May 13, 2010 at 4:08 AM, Luke Plant  wrote:

> On Thursday 13 May 2010 01:14:35 fitzgen wrote:
>
> > * 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-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: Class based generic views in 1.3?

[Nick Fitzgerald]

Another option that hasn't come up is to just have a custom __setattr__ that
won't let users write to self (therefore providing primitive thread safety).
I don't think it is a /good/ option, but I am just throwing it out there for
completeness.

_Nick_



On Tue, Jun 15, 2010 at 7:10 AM, Patryk Zawadzki wrote:

> If you don't mind, I'll talk a bit more to myself.
>
> On Tue, Jun 15, 2010 at 3:38 PM, Patryk Zawadzki 
> wrote:
> > I really don't think we should add anti-moron filters at the framework
> > level past documenting "taking care to ensire immutability of view
> > instances".
>
> This came out a bit harsh. What I mean is: teach users how to write
> thread-safe views (classes or not) and ignore those who refuse to do
> it. They either know what they're doing or there is really no point in
> forcing the help upon them.
>
> --
> Patryk Zawadzki
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: Class based generic views in 1.3?

[Nick Fitzgerald]

I have forked bfirsh's code as well on github:
http://github.com/fitzgen/django-class-based-views

I have changed the code
to use __new__ rather than copying self. I have also merged in daonb's
commit to make request implicit to all methods via self.request.

All feedback is very welcome! :)

_Nick_



On Wed, Jun 16, 2010 at 4:14 PM, daonb  wrote:

> On Jun 16, 4:45 pm, Ben Firshman  wrote:
> >
> > The request is passed round so methods look like views to decorators.
> Magically dropping it for decorators seems a bit scary. :/
> >
>
> The way I see it a good framework need to establish a clear contract
> with its user. In our case, Django publishes a contract ensuring the
> user that when he inherits from View and overrides any of: GET, POST,
> UPDATE, DELETE,get_response, get_content, get_resource, render_html,
> get_template, get_context and a few others, the request attribute of
> self is current.
>
> I agree stripping the request looks a bit scary, but at least it's
> only 5 lines of simple code:-). They way I see it,  decorators are
> global so they need the request and Django adds it for them. When the
> global decorators are done, Django can strip the request and get the
> user to trust our contract.
>
> Benny.
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: Class based generic views in 1.3?

[Nick Fitzgerald]

>
> It's still possible in exactly the same way as you do it today:
> mydata = ...
> urlpatterns('', url('...', 'MyView', {'outside_of_lifecycle': mydata}))
>
> Alternatively, you can derive from MyView:
> class SubMyView(MyView):
>ouside_of_lifecycle = mydata
>
> However, I don't think that this is the use-case of class-based views
> (you can achieve the same with function-based views). The whole point
> is being able to reuse as much code as possible while allowing to
> flexibly modify the view's behavior at a rather fine-grained level.
> Take a look at the Feed view in Django (or look at ModelAdmin from the
> admin interface if you prefer):
> http://docs.djangoproject.com/en/dev/ref/contrib/syndication/
> You can customize the query that gets executed and you can customize
> every single field that gets displayed in the feed. It's very easy and
> flexible and in contrast to function-based views you don't need to
> rewrite the whole view from scratch to change a little detail.
>
>
Yes. I couldn't have put the use case for class based generic views in to
words better myself.

_Nick_

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