On Thu, Jun 17, 2010 at 6:57 PM, Patryk Zawadzki <pat...@pld-linux.org> wrote:
> On Thu, Jun 17, 2010 at 6:49 PM, Waldemar Kornewald
> <wkornew...@gmail.com> wrote:
>> The one-instance approach is no more thread-safe than having a global
>> variable. In your example nothing bad will happen, but once we get to
>> some real-world reusable views you'll quickly see a need for saving
>> thread-local state somewhere. We had that problem with Django's Feed
>> class, for example, where we needed access to the request in one of
>> the methods and the only workaround was to instantiate a new Feed for
>> every request and manually inject a _request attribute. The point is
>> that in a class-based view you normally have lots of methods for
>> customizing the view's behavior, so either you pass the whole
>> thread-local state as arguments to every single method (which is
>> *very* ugly and tedious) or you save that state in self. Also, the
>> problem with passing lots of arguments around is that it can make
>> adding more variables to the current state and thus customizability
>> difficult. There's no way around allowing thread-local state and the
>> one instance per request approach solves this elegantly.
>
> So the only limitation is that you don't want to pass parameters to methods?
Imagine what the code would look like with parameter passing:
class View(object):
def __call__(self, request, **kwargs):
qs = self.get_queryset(request, **kwargs)
.....
def get_queryset(self, request, **kwargs):
...
Now someone writes a reusable view for S3 file management which only
has one parameter (bucket_name) and publishes the code as an
open-source project:
class S3View(View):
def get_queryset(request, bucket_name, **kwargs):
self.get_bucket(bucket_name)
...
...
Then you want to use his code in your project:
class MyS3View(S3View):
def get_bucket(self, bucket_name):
# oh no! I need the request and the other configuration
paramters here! :(
Now you have a problem because the other developer was too lazy to
pass request and **kwargs to that little "unimportant" get_bucket
method. This happens in practice and our job is to come up with a
design that makes this impossible or very unlikely. If the
one-instance-per-request solution solves this and saves you from
typing **kwargs all over the place then it absolutely is better, hands
down.
Bye,
Waldemar Kornewald
--
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.
