On Oct 3, 1:02 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Sun, Oct 3, 2010 at 12:12 PM, Ian Lewis <ianmle...@gmail.com> wrote:
> > On Sun, Oct 3, 2010 at 11:20 AM, Russell Keith-Magee
> > <russ...@keith-magee.com> wrote:
> > While I'm in the "one singleton view instance is best" camp and think
> > that storing some state on the request and some on the view is a bit
> > gross, I understand Russell's arguments. New users are simply going to
> > save stuff on self no matter how much we complain, document etc. It's
> > simply a reality that likely can't be helped much.
>
> > Other frameworks seem have View/Handler instances per request, such as
> > appengine's webapp so there is some precedent for creating an instance
> > per request.
>
> >http://code.google.com/appengine/docs/python/gettingstarted/handlingf...
>
> I don't think you'll find any argument that having an instance per
> request would solve all the problems that this thread has described.
> The issue is how to declare a view that is able to be instantiated on
> a instance-per-request basis while simultaneously allowing decorators
> to be easily wrapped around that view.
>
> Yours,
> Russ Magee %-)
I haven't investigated the other solutions described in this
discussion, but the solution I proposed handles decorators just fine.
class BaseView(object):
def __new__(cls, *args, **kwargs):
obj = super(BaseView, cls).__new__(cls)
# Call __init__ manually since it will not be called
# after this method (since __new__ returns a HttpResponse
# and not a BaseView subclass).
obj.__init__(*args, **kwargs)
return obj.view() # Or other name
class MyView(BaseView):
def __init__(self, request):
self.request = request
def view(self):
return HttpResponse(self.request.path)
urlpatterns = patterns("", ("^login_required_view/$",
login_required(MyView)))
Best regards,
André Eriksson
--
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.
