Make "required=True" on forms.fields.NullBooleanField do something useful?
My use case is that I want to have a BooleanField on the model and on the form want to have the choices of "Unknown", "Yes" and "No" in a select list and give a "this field is required" error if the user leaves it set to "Unknown" (i.e. require them to actively choose "Yes" or "No", rather than defaulting to either of them). I thought I'd just be able to use NullBooleanField with "required=True" set, but NullBooleanField just ignores the "required" argument. To my mind it would be a sensible use of "required" for NullBooleanField, but before raising a ticket I thought I'd ask if it was a deliberate oversight or if what I'm suggesting isn't sensible for some reason :). Looking at the code for forms.fields.BooleanField and forms.fields.NullBooleanField I guess the change would be in to_python in the latter to check in the case where it would return None if self.required is true and raise the validation error if that's the case (i.e. similar to what BooleanField.to_python does for values of False). Matt -- 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?
On 16 jun, 15:45, Ben Firshman wrote:
> The request is passed round so methods look like views to decorators.
> Magically dropping it for decorators seems a bit scary. :/
Just brainstorming: couldn't you have View derive from HttpRequest?
Then you get a request object as the first parameter of methods, and
you can apply decorators to them (untested):
class View(HttpRequest):
def __new__(cls, request, *args, **kwargs):
"""
make sure not to call HttpRequest.__init__ on the request
again,
since it has already been initialized
"""
request.__class__ = cls # or maybe make a copy of
request first
return request(*args, **kwargs)
@login_required
def __call__(request, *args, **kwargs):
return HttpResponse('')
--
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: Make "required=True" on forms.fields.NullBooleanField do something useful?
On Jun 17, 11:39 am, Matt Hoskins wrote: > My use case is that I want to have a BooleanField on the model and on > the form want to have the choices of "Unknown", "Yes" and "No" in a > select list and give a "this field is required" error if the user > leaves it set to "Unknown" (i.e. require them to actively choose "Yes" > or "No", rather than defaulting to either of them). I thought I'd just > be able to use NullBooleanField with "required=True" set, but > NullBooleanField just ignores the "required" argument. To my mind it > would be a sensible use of "required" for NullBooleanField, but before > raising a ticket I thought I'd ask if it was a deliberate oversight or > if what I'm suggesting isn't sensible for some reason :). If you require a "Yes" or "No" choice, why do you use a NullBooleanField in the first place and not a BooleanField ? George -- 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?
On Thu, Jun 17, 2010 at 11:53 AM, Roald wrote: > On 16 jun, 15:45, Ben Firshman wrote: >> The request is passed round so methods look like views to decorators. >> Magically dropping it for decorators seems a bit scary. :/ > > Just brainstorming: couldn't you have View derive from HttpRequest? Would you seriously recommend people to extend "int" when they want to implement multiplication? :) -- 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.
Re: Class based generic views in 1.3?
On Thu, Jun 17, 2010 at 1:44 AM, Nick Fitzgerald wrote:
> 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! :)
Is there any reason why all of you think not passing request around is a gain?
Would you recommend anyone to do:
8<
request = None
def my_view():
global request
return HttpResponse('Hi, %s' % (request.user.get_full_name(), ))
def my_other_view():
globl request
return HttpResponse('Hello again, %s' % (request.user.get_full_name(), ))
# ...
8<
As I seriously see no difference between this and pushing stuff to self.request.
Request objects are esoteric. They are only meaningful during that
short period of time you spend in the __call__ method. Once you return
a HttpResponse, request is ready to retire. Storing them at the level
objects grants them potentially eternal life for no reason.
Consider this:
8<
class AwesomeAdd(object):
def __call__(self, number1, nubmer2):
self.number1 = number1
self.number2 = number2
return self.do_the_math()
def do_the_math(self):
# OMG BBQ, we cleverly avoided passing params around!!1!one
return self.number1 + self.number2
aa = AwesomeAdd()
foo = aa(3, 5)
8<
Doesn't that scream "WTF"? :)
--
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.
Re: Make "required=True" on forms.fields.NullBooleanField do something useful?
For the reasons I gave in my explanation above - which bit isn't clear? > If you require a "Yes" or "No" choice, why do you use a > NullBooleanField in the first place and not a BooleanField ? > > George -- 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: Make "required=True" on forms.fields.NullBooleanField do something useful?
On 17 June 2010 13:01, Matt Hoskins wrote: > For the reasons I gave in my explanation above - which bit isn't > clear? Why not reuse the NullBoolean widget with a Boolean field? HM -- 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?
On Thu, Jun 17, 2010 at 1:44 AM, Nick Fitzgerald wrote: > 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! :) The __new__-based approach is just lovely. :) Really, it's much more elegant than copying self and it's very convenient to be able to access self.request and the configuration options from anywhere. This solves a lot of problems when you want to customize a view's behavior. We really missed this when we used Django's class-based Feed view. Some minor issues: The __init__ function isn't called with *args, **kwargs (at least, I think this was an oversight). FormView.POST should probably use self.get_content like View.GET does by default. Should there be different methods for each request.method, at all? Often form POST handling code can reuse the GET part if form validation fails. By splitting everything up in two methods you blow up the code unnecessarily. BTW, I think the current code would unnecessarily instantiate the form two times if the form doesn't validate. Also, _load_config_values should guarantee that you don't pass unsupported arguments. This should also work with inheritance. 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.
Re: Make "required=True" on forms.fields.NullBooleanField do something useful?
Because "required=True" on a BooleanField means "raise a required validation error if the value is anything other than True" so although using that combination that would give me the drop down list, it wouldn't give me the behaviour I desire which is to only raise the validation error if None is selected. I could handle it on the form, it just seems to me that given "required=True" is ignored on NullBooleanField it would be a sensible (and logical) use for it to have it mean "require the user to pick either Yes or No". (George - in case this is where you're not clear - in my use case I don't want the user to be able to just hit the submit button without having actively selected either "Yes" or "No" for these fields - if the choices were just "Yes" or "No" then one of those would have to be the default and thus the default value would be valid so the user could just hit submit without interacting with the field, whereas if the selection list includes "Unknown" and defaults to that, the user has to interact with the field and change it to "Yes" or "No" to pass validation). On Jun 17, 12:07 pm, Hanne Moa wrote: > On 17 June 2010 13:01, Matt Hoskins wrote: > > > For the reasons I gave in my explanation above - which bit isn't > > clear? > > Why not reuse the NullBoolean widget with a Boolean field? > > HM -- 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?
On Thu, Jun 17, 2010 at 12:26 PM, Patryk Zawadzki wrote:
> On Thu, Jun 17, 2010 at 1:44 AM, Nick Fitzgerald wrote:
>> 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! :)
>
> Is there any reason why all of you think not passing request around is a gain?
>
> Would you recommend anyone to do:
>
> 8<
>
> request = None
>
> def my_view():
> global request
> return HttpResponse('Hi, %s' % (request.user.get_full_name(), ))
>
> def my_other_view():
> globl request
> return HttpResponse('Hello again, %s' % (request.user.get_full_name(), ))
>
> # ...
>
> 8<
>
> As I seriously see no difference between this and pushing stuff to
> self.request.
Please take a deeper look at his code. He doesn't use __init__. He
uses __new__, so each request gets his own View instance.
Instead of
aa = AwesomeAdd()
foo = aa(3, 5)
the __new__-based approach allows to do this:
foo = AwesomeAdd(3, 5)
IOW, the "constructor" directly returns an HttpResponse (foo) instead
of an AwesomeAdd instance.
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.
Re: Class based generic views in 1.3?
On Thu, Jun 17, 2010 at 1:20 PM, Waldemar Kornewald
wrote:
> Please take a deeper look at his code. He doesn't use __init__. He
> uses __new__, so each request gets his own View instance.
>
> Instead of
>
> aa = AwesomeAdd()
> foo = aa(3, 5)
>
> the __new__-based approach allows to do this:
>
> foo = AwesomeAdd(3, 5)
>
> IOW, the "constructor" directly returns an HttpResponse (foo) instead
> of an AwesomeAdd instance.
There is no difference between using __init__ and __new__ as long as
you treat the instance as a junkyard for temporary variables. If done
properly, class-based views do _not_ need a separate instance for each
request.
Here's an example of a thread-safe view that works happily with just
one instance:
8<
class MyView(object):
def __init__(self, queryset, template='bar.html'):
self.qs = queryset
self.template = template
def __call__(self, request, id):
instance = get_object_or_404(self.qs, id=id)
return direct_to_template(request, self.template, {'object': instance})
# ...
url(r'^foo/(?P\d+)/', MyView(queryset=Foo.objects.all(),
template='foo.html')),
8<
--
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.
Re: Make "required=True" on forms.fields.NullBooleanField do something useful?
> > Looking at the code for forms.fields.BooleanField and > forms.fields.NullBooleanField I guess the change would be in to_python > in the latter to check in the case where it would return None if > self.required is true and raise the validation error if that's the > case (i.e. similar to what BooleanField.to_python does for values of > False). As an aside, I'm now wondering if it's actually incorrect in Django 1.2 that BooleanField.to_python is what does the self.required check - shouldn't it be done in a method called validate? The documentation for the field api for 1.2 says "the to_python() method on a Field is the first step in every validation, it coerces the value to correct datatype and raises ValidationError if that is not possible" - I'd argue that False is of the correct data type (i.e. just because required is set to True doesn't mean that False now is not of the correct data type for BooleanField) so to_python shouldn't be doing this check. I think it's probably an oversight as the code that's now in "to_python" on BooleanField in 1.2 is what was in "clean" in 1.1, so it was probably just moved wholesale. Matt -- 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?
On 17 jun, 12:16, Patryk Zawadzki wrote: > On Thu, Jun 17, 2010 at 11:53 AM, Roald wrote: > > On 16 jun, 15:45, Ben Firshman wrote: > >> The request is passed round so methods look like views to decorators. > >> Magically dropping it for decorators seems a bit scary. :/ > > > Just brainstorming: couldn't you have View derive from HttpRequest? > > Would you seriously recommend people to extend "int" when they want to > implement multiplication? :) Nope. But the analogy doesn't hold. First: this is just brainstorming. Maybe it inspires someone for a better solution somehow. As you might know, I (still) favor deriving from HttpResponse Second: users will never extend HttpRequest directly, they will extend View. Third: It might be not even as weird as it looks on first sight. There's nothing wrong with 'response = request.get_response()', so why not just make 'get_response' the 'default function' of a request: response = request(). I admint that the name View might nog be the best in this case. Fourth: still, this is just brainstorming. -- 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?
On Thu, Jun 17, 2010 at 1:42 PM, Patryk Zawadzki wrote:
> On Thu, Jun 17, 2010 at 1:20 PM, Waldemar Kornewald
> wrote:
>> Please take a deeper look at his code. He doesn't use __init__. He
>> uses __new__, so each request gets his own View instance.
>>
>> Instead of
>>
>> aa = AwesomeAdd()
>> foo = aa(3, 5)
>>
>> the __new__-based approach allows to do this:
>>
>> foo = AwesomeAdd(3, 5)
>>
>> IOW, the "constructor" directly returns an HttpResponse (foo) instead
>> of an AwesomeAdd instance.
>
> There is no difference between using __init__ and __new__ as long as
> you treat the instance as a junkyard for temporary variables. If done
> properly, class-based views do _not_ need a separate instance for each
> request.
>
> Here's an example of a thread-safe view that works happily with just
> one instance:
>
> 8<
>
> class MyView(object):
> def __init__(self, queryset, template='bar.html'):
> self.qs = queryset
> self.template = template
>
> def __call__(self, request, id):
> instance = get_object_or_404(self.qs, id=id)
> return direct_to_template(request, self.template, {'object': instance})
>
> # ...
>
> url(r'^foo/(?P\d+)/', MyView(queryset=Foo.objects.all(),
> template='foo.html')),
This is not at all thread-safe because all requests share the same
view instance and thus the same state. Shared state is not thread-safe
(unless you introduce some locking mechanism which is not an option
here). Thread-safety can only be guaranteed if every thread has its
own state. In other words, every request needs his own View instance.
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.
Re: Class based generic views in 1.3?
On Thu, Jun 17, 2010 at 1:05 PM, Roald wrote: > On 17 jun, 12:16, Patryk Zawadzki wrote: >> On Thu, Jun 17, 2010 at 11:53 AM, Roald wrote: >> > On 16 jun, 15:45, Ben Firshman wrote: >> >> The request is passed round so methods look like views to decorators. >> >> Magically dropping it for decorators seems a bit scary. :/ >> >> > Just brainstorming: couldn't you have View derive from HttpRequest? >> >> Would you seriously recommend people to extend "int" when they want to >> implement multiplication? :) > > Nope. But the analogy doesn't hold. > > First: this is just brainstorming. Maybe it inspires someone for a > better solution somehow. As you might know, I (still) favor deriving > from HttpResponse > > Second: users will never extend HttpRequest directly, they will extend > View. > > Third: It might be not even as weird as it looks on first sight. > There's nothing wrong with 'response = request.get_response()', so why > not just make 'get_response' the 'default function' of a request: > response = request(). I admint that the name View might nog be the > best in this case. > > Fourth: still, this is just brainstorming. > A few points: 1) With inheritance, you should be able to say Derived is-a Base, eg 'a Car is-a Vehicle'. A view is NOT a response, however you wrap it up. A view is a generator that when called with a request, results in a response, whether it is a class based view, or a function based view. Does a view have headers or a mime type? Perhaps you need to start using different names for these classes, because inferring that 'a view is-a response' just sounds stupid. 2) I extend HttpResponse. In lots of places. (more to the __new__ approach) 3) One of the purposes (as far as I can see) of having the view as a class is to allow non volatile application data to be instantiated outside of the request-response lifecycle. In the proposed approach, each request is effectively given its own cloned view object with which to generate the response. Surely this means this use case is no longer achievable? If it is, how? (I'm probably missing something!) If it isn't, then what _is_ the use case for class based views? Cheers Tom -- 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?
I've written about using __new__ to generate HttpResponse objects in the past (see http://codysoyland.com/2010/feb/3/thread-safe-object-oriented-views-django/ and the relevant discussion thread), and this approach solves the thread-safety and boilerplate-reduction concerns. However, when implementing this, the one problem I've been fighting is testing. In order to test methods on a view built this way is to instantiate it using object.__new__ and explicitly calling __init__ before you can start to test view methods, and this may not be clear to somebody who is writing their first class-based view tests. Increasingly, I've been warming up to the idea of django treating class-based views a little bit more special: If the view is a subclass of BaseView, call it's to_response method instead of treating it as a callable. The public API would be more clear. You pass in the request object into __init__ instead of __call__; you don't have __new__ hacks; testing is a breeze; you don't have to do any factory wrappers a la http://github.com/toastdriven/django-haystack/commit/e93be1d142372afa1687fb3e35966c1ccec76241 -- 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?
On Thu, Jun 17, 2010 at 3:32 PM, Tom Evans wrote:
> A few points:
>
> 1) With inheritance, you should be able to say Derived is-a Base, eg
> 'a Car is-a Vehicle'. A view is NOT a response, however you wrap it
> up. A view is a generator that when called with a request, results in
> a response, whether it is a class based view, or a function based
> view. Does a view have headers or a mime type?
>
> Perhaps you need to start using different names for these classes,
> because inferring that 'a view is-a response' just sounds stupid.
>
> 2) I extend HttpResponse. In lots of places.
I'd like to add here that we already discussed the biggest
disadvantage of deriving from HttpResponse:
With this approach you can't easily pass the request to some other view:
def main_view(request, ...):
if ...:
return sub_view(request, ...)
else:
return other_sub_view(request, ...)
This is a common pattern and it can occur somewhere deep within the
view code. The HttpResponse approach doesn't provide an easy solution.
It doesn't even provide an easy solution for returning
HttpResponseRedirect or other HttpResponse subclasses, as you already
identified.
> (more to the __new__ approach)
> 3) One of the purposes (as far as I can see) of having the view as a
> class is to allow non volatile application data to be instantiated
> outside of the request-response lifecycle.
> In the proposed approach, each request is effectively given its own
> cloned view object with which to generate the response. Surely this
> means this use case is no longer achievable?
> If it is, how? (I'm probably missing something!) If it isn't, then
> what _is_ the use case for class based views?
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.
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.
Re: Class based generic views in 1.3?
>
> 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.
Re: Class based generic views in 1.3?
On 17 jun, 15:32, Tom Evans wrote:
> 1) With inheritance, you should be able to say Derived is-a Base,
I agree very much.
> eg
> 'a Car is-a Vehicle'. A view is NOT a response, however you wrap it
> up. A view is a generator that when called with a request, results in
> a response, whether it is a class based view, or a function based
> view. Does a view have headers or a mime type?
>
> Perhaps you need to start using different names for these classes,
> because inferring that 'a view is-a response' just sounds stupid.
I agree. So the question becomes: should we use views or http
responses. Personally, I think a view is a pretty abstract concept
('something that turns a request in a response'), and I would prefer
something more graspable.
--
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?
On Thu, Jun 17, 2010 at 2:08 PM, Waldemar Kornewald
wrote:
> On Thu, Jun 17, 2010 at 1:42 PM, Patryk Zawadzki wrote:
>> Here's an example of a thread-safe view that works happily with just
>> one instance:
>>
>> 8<
>>
>> class MyView(object):
>> def __init__(self, queryset, template='bar.html'):
>> self.qs = queryset
>> self.template = template
>>
>> def __call__(self, request, id):
>> instance = get_object_or_404(self.qs, id=id)
>> return direct_to_template(request, self.template, {'object':
>> instance})
>>
>> # ...
>>
>> url(r'^foo/(?P\d+)/', MyView(queryset=Foo.objects.all(),
>> template='foo.html')),
> This is not at all thread-safe because all requests share the same
> view instance and thus the same state. Shared state is not thread-safe
> (unless you introduce some locking mechanism which is not an option
> here). Thread-safety can only be guaranteed if every thread has its
> own state. In other words, every request needs his own View instance.
You don't seem to get how threading works.
There is no state in this object past the assignments in __init__.
These are thread-safe as there is only one instance of the object.
Variables in local scope are always thread-safe as reetrancy grants
you a new local scope every time it enters a function.
--
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.
Re: Class based generic views in 1.3?
The example he provided isn't terribly good but you don't need an view
instance per request (the example will work unless you start adding
stuff to self or overwriting self.qs etc). Only shared state is stored
at the class level and view customization is done at the class
instance level as well. That state shouldn't change.
Attaching all kinds of stuff to self tends to depend on the order of
the methods called and allows for some ugly coding styles. In that
case the slightly strange idea of merging the request and the view by
extending HttpRequest starts to make sense since otherwise you would
have some state on the request object (like the user etc. as it is
now) and some state on the view object.
That said, both extending HttpRequest and using __new__ seem like a
hacks to me. Personally the idea of a view being a callable class
instance or method is simple and flexable enough to handle any use
cases we are talking about. You just have to think of self as the
*view* rather than a thread safe request because that's what it is.
Having a view object per request makes no sense. You should have a
request object per request. It is largely a result of wanting the
convenience of being able to write sloppy code that writes all kinds
of state to self rather than a technical necessity.
Ian
On Thursday, June 17, 2010, Waldemar Kornewald wrote:
> On Thu, Jun 17, 2010 at 1:42 PM, Patryk Zawadzki wrote:
>> On Thu, Jun 17, 2010 at 1:20 PM, Waldemar Kornewald
>> wrote:
>>> Please take a deeper look at his code. He doesn't use __init__. He
>>> uses __new__, so each request gets his own View instance.
>>>
>>> Instead of
>>>
>>> aa = AwesomeAdd()
>>> foo = aa(3, 5)
>>>
>>> the __new__-based approach allows to do this:
>>>
>>> foo = AwesomeAdd(3, 5)
>>>
>>> IOW, the "constructor" directly returns an HttpResponse (foo) instead
>>> of an AwesomeAdd instance.
>>
>> There is no difference between using __init__ and __new__ as long as
>> you treat the instance as a junkyard for temporary variables. If done
>> properly, class-based views do _not_ need a separate instance for each
>> request.
>>
>> Here's an example of a thread-safe view that works happily with just
>> one instance:
>>
>> 8<
>>
>> class MyView(object):
>>def __init__(self, queryset, template='bar.html'):
>>self.qs = queryset
>>self.template = template
>>
>>def __call__(self, request, id):
>>instance = get_object_or_404(self.qs, id=id)
>>return direct_to_template(request, self.template, {'object':
>> instance})
>>
>> # ...
>>
>>url(r'^foo/(?P\d+)/', MyView(queryset=Foo.objects.all(),
>> template='foo.html')),
>
> This is not at all thread-safe because all requests share the same
> view instance and thus the same state. Shared state is not thread-safe
> (unless you introduce some locking mechanism which is not an option
> here). Thread-safety can only be guaranteed if every thread has its
> own state. In other words, every request needs his own View instance.
>
> 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.
>
>
--
===
株式会社ビープラウド イアン・ルイス
〒150-0021
東京都渋谷区恵比寿西2-3-2 NSビル6階
email: ianmle...@beproud.jp
TEL:03-6416-9836
FAX:03-6416-9837
http://www.beproud.jp/
===
--
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?
2010/6/17 Ian Lewis : > The example he provided isn't terribly good but you don't need an view > instance per request (the example will work unless you start adding > stuff to self or overwriting self.qs etc). Only shared state is stored > at the class level and view customization is done at the class > instance level as well. That state shouldn't change. > > Attaching all kinds of stuff to self tends to depend on the order of > the methods called and allows for some ugly coding styles. In that > case the slightly strange idea of merging the request and the view by > extending HttpRequest starts to make sense since otherwise you would > have some state on the request object (like the user etc. as it is > now) and some state on the view object. > > That said, both extending HttpRequest and using __new__ seem like a > hacks to me. Personally the idea of a view being a callable class > instance or method is simple and flexable enough to handle any use > cases we are talking about. You just have to think of self as the > *view* rather than a thread safe request because that's what it is. > > Having a view object per request makes no sense. You should have a > request object per request. It is largely a result of wanting the > convenience of being able to write sloppy code that writes all kinds > of state to self rather than a technical necessity. You, sir, deserve a beer! -- 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.
Re: Class based generic views in 1.3?
On Thu, Jun 17, 2010 at 6:08 PM, Patryk Zawadzki wrote:
> On Thu, Jun 17, 2010 at 2:08 PM, Waldemar Kornewald
> wrote:
>> On Thu, Jun 17, 2010 at 1:42 PM, Patryk Zawadzki
>> wrote:
>>> Here's an example of a thread-safe view that works happily with just
>>> one instance:
>>>
>>> 8<
>>>
>>> class MyView(object):
>>> def __init__(self, queryset, template='bar.html'):
>>> self.qs = queryset
>>> self.template = template
>>>
>>> def __call__(self, request, id):
>>> instance = get_object_or_404(self.qs, id=id)
>>> return direct_to_template(request, self.template, {'object':
>>> instance})
>>>
>>> # ...
>>>
>>> url(r'^foo/(?P\d+)/', MyView(queryset=Foo.objects.all(),
>>> template='foo.html')),
>> This is not at all thread-safe because all requests share the same
>> view instance and thus the same state. Shared state is not thread-safe
>> (unless you introduce some locking mechanism which is not an option
>> here). Thread-safety can only be guaranteed if every thread has its
>> own state. In other words, every request needs his own View instance.
>
> You don't seem to get how threading works.
Let's keep the discussion productive and not talk BS.
> There is no state in this object past the assignments in __init__.
> These are thread-safe as there is only one instance of the object.
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.
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.
Re: Class based generic views in 1.3?
On Thu, Jun 17, 2010 at 6:49 PM, Waldemar Kornewald 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? Good thing self is passed implicitly or classes would be totally useless! ;) More seriously: Explicit is better than implicit. Simple is better than complex. [...] If the implementation is hard to explain, it's a bad idea. -- 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.
Re: Class based generic views in 1.3?
On Thu, Jun 17, 2010 at 6:57 PM, Patryk Zawadzki wrote: > On Thu, Jun 17, 2010 at 6:49 PM, Waldemar Kornewald > 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.
Re: Class based generic views in 1.3?
2010/6/17 Ian Lewis : > Attaching all kinds of stuff to self tends to depend on the order of > the methods called and allows for some ugly coding styles. In that > case the slightly strange idea of merging the request and the view by > extending HttpRequest starts to make sense since otherwise you would > have some state on the request object (like the user etc. as it is > now) and some state on the view object. My view is that request=="input data", view class=="execution" and view instance=="execution environment". Function-based views are pretty much the same, but you just don't have to care about the environment, because it's composed out of your local variables. > > That said, both extending HttpRequest and using __new__ seem like a > hacks to me. Personally the idea of a view being a callable class > instance or method is simple and flexable enough to handle any use > cases we are talking about. You just have to think of self as the > *view* rather than a thread safe request because that's what it is. I agree about HttpRequest. As Tom pointed out Request is not a View. It just doesn't fit the inheritance. As for the __new__, I guess it's just two diffrent approaches and in the end you get pretty much the same thing. I think of "self" as "environment" and the class as "view". In one instance approach, the instance is the "view" and "environment" is in method parameters or request (is this right?). Anyway, I think this discussion in on a wrong track. From a Django user POV, I really don't care how it's implemented. I'm far more concerned with the API that generic views will provide. -- Łukasz Rekucki -- 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?
On Thu, Jun 17, 2010 at 3:58 PM, codysoyland wrote: > I've written about using __new__ to generate HttpResponse objects in > the past (see > http://codysoyland.com/2010/feb/3/thread-safe-object-oriented-views-django/ > and the relevant discussion thread), and this approach solves the > thread-safety and boilerplate-reduction concerns. However, when > implementing this, the one problem I've been fighting is testing. In > order to test methods on a view built this way is to instantiate it > using object.__new__ and explicitly calling __init__ before you can > start to test view methods, and this may not be clear to somebody who > is writing their first class-based view tests. > > Increasingly, I've been warming up to the idea of django treating > class-based views a little bit more special: If the view is a subclass > of BaseView, call it's to_response method instead of treating it as a > callable. You have a strong point here. We could at least provide a new_instance(request, *args, **kwargs) classmethod for unit tests which automates the __new__ and __init__ calls. Anyway, I'm not sure which is worth more: * relatively easy for unit tests (new_instance()) * enforced thread-safety * no special code in Django's URL routing vs * no-brainer for unit tests * no enforced thread-safety (you can mistakenly create a global view instance) * special code in Django's URL routing 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.
Re: Class based generic views in 1.3?
On Thu, Jun 17, 2010 at 8:00 PM, Waldemar Kornewald
wrote:
> 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):
> ...
Why would you hardcore the queryset inside the view? Pass the
pre-filtered queryset to the constructor and use get_objects_or_404 to
filter it basing on what is passed to __call__.
Actually as I see it __call__ is not the best idea:
class GenericView(object):
def __init__(self, queryset):
self.qs = queryset
def details(self, request, id):
obj = get_object_or_404(self.qs, id=id)
return direct_to_template(request, 'details.html', {'object': obj})
def list(self, request):
objs = get_objects_or_404(self.qs)
return direct_to_template(request, 'list.html', {'objects': objs})
# ... and so on
> 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)
> ...
> ...
Are you sure you need to pass the bucket name each time you _call_ the
view? I'd pass it at construction time instead.
> 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! :(
Request sure, but what other configuration parameters? Default
implementation should under no circumstances pass and silently swallow
**kwargs.
> 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.
See above.
--
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.
django snippets site as a wiki
As all of you know, djangosnippets.com is very popular and a pretty integral part of the Django ecosystem. It is a great resource but there are some problems: 1. The site has been online for a few years, and the majority of the snippets were added back in the 1.0 and pre-1.0 era. Many of those snippets no longer work. Some of the snippets have comments containing how to get the snippet working in the current version of Django, but many do not. A lot of snippets have been more or less abandoned by their original poster. 2. The snippets are not very well organized. For instance, one can't bring up a list of snippets that are custom widgets. You can search, but it's not the same. The software is pretty basic and doesn't have many features (relative to Mediawiki). 3. The site hasn't been maintained much over the years. A few months ago I tried to sign up, but a confirmation email never came. I tried a few more times, but still couldn't get an account created. This is my proposal: We get rid of djangosnippets as it is now, and replace it with a Mediawiki. The benefits are as follows: 1. Mediawiki is maintained by a group of people who are able to put way more effort into the software than djangosnippets can. 2. Each snippet is editable. Over time, instead of each snippet being unmaintained, users can add whatever is necessary to make the snippet work again. Mediawiki keeps track of change-sets so vandalism can be reverted. 3. A wiki is more flexible. Each page can be a snippet. Or you can have more than one snippets to one page. Maybe one version of the snippet for Django version 1.0, another version for 1.1, and a third version of the snippets for 1.2 all on the same page. You can also link to other snippets from snippets pages. 4. Better categorization. Mediawiki has a great automatic categorization system. You basically add a tag to a page and it automatically adds it to the category page. We can tag snippets as "Form Field", "Middleware", or "Widget" to denote what kind of snippet is is. We can put all snippets that do not work currently into a "Does not work in 1.2" category to denote all snippets that need to be fixed, etc, etc. And here are the downsides: 1. The current djangosnippets site has a lot of momentum. It's going to be hard to convince people to change it up. We need everyone to be on board to make it happen. I don't want to just create such a site without getting everyone's blessing because community fragmentation is a bad thing. 2. Mediawiki will have to be themed to make it look like the rest of the sites in the Django community (green and white color scheme). Mediawiki is skinnable so this shouldn't be too much of a problem. 3. Django snippets currently references all snippets by a number, such as snippet #1200 or snippet #458. Switching to Mediawiki gets rid of this. There may still be a way to still get pages to be referenced by their primary key, but I'll have to look into it. Is this even an important issue? 4. Mediawiki is not Django. How will this make us look if we used a PHP site to track our snippets? Is this even an issue? I don't think it is, but others may think differently. If there was a native wiki engine for Django we could use that, but such does not exist. -- 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?
Am 17.06.2010 um 18:23 schrieb Ian Lewis: The example he provided isn't terribly good but you don't need an view instance per request (the example will work unless you start adding stuff to self or overwriting self.qs etc). Only shared state is stored at the class level and view customization is done at the class instance level as well. That state shouldn't change. Attaching all kinds of stuff to self tends to depend on the order of the methods called and allows for some ugly coding styles. In that case the slightly strange idea of merging the request and the view by extending HttpRequest starts to make sense since otherwise you would have some state on the request object (like the user etc. as it is now) and some state on the view object. That said, both extending HttpRequest and using __new__ seem like a hacks to me. Personally the idea of a view being a callable class instance or method is simple and flexable enough to handle any use cases we are talking about. You just have to think of self as the *view* rather than a thread safe request because that's what it is. Having a view object per request makes no sense. You should have a request object per request. It is largely a result of wanting the convenience of being able to write sloppy code that writes all kinds of state to self rather than a technical necessity. Ian I'd like to support Ian and Patryk's position: class based views should not be instantiated for each request - for all the reasons Ian gave in the quoted mail. If you want to avoid passing around (lots of) arguments between methods, you can always store request specific state on the request instance, which is a common pattern for middleware already. To prevent the request's dict from becoming too cluttered, simply put the arguments into `request.view_context` (a dict or similar container, needs to be painted). __ Johannes -- 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: django snippets site as a wiki
On Thu, Jun 17, 2010 at 3:32 PM, dffdgsdfgsdfhjhtre wrote: > This is my proposal: We get rid of djangosnippets as it is now, and > replace it with a Mediawiki. The benefits are as follows: FYI, djangosnippets isn't run by the Django core team, or anyone really associated directly with us. IOW, it's a private site, not subject to our oversight or review or anything. That said, your suggestions are sensible enough -- though personally I think MediaWiki is a load of ... ahem .. -- so you probably should get in touch with Charles or James (see links in the footer) and offer to help out. 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-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?
On Thu, Jun 17, 2010 at 3:35 PM, Johannes Dollinger wrote: > Am 17.06.2010 um 18:23 schrieb Ian Lewis: > >> The example he provided isn't terribly good but you don't need an view >> instance per request (the example will work unless you start adding >> stuff to self or overwriting self.qs etc). Only shared state is stored >> at the class level and view customization is done at the class >> instance level as well. That state shouldn't change. >> >> Attaching all kinds of stuff to self tends to depend on the order of >> the methods called and allows for some ugly coding styles. In that >> case the slightly strange idea of merging the request and the view by >> extending HttpRequest starts to make sense since otherwise you would >> have some state on the request object (like the user etc. as it is >> now) and some state on the view object. >> >> That said, both extending HttpRequest and using __new__ seem like a >> hacks to me. Personally the idea of a view being a callable class >> instance or method is simple and flexable enough to handle any use >> cases we are talking about. You just have to think of self as the >> *view* rather than a thread safe request because that's what it is. >> >> Having a view object per request makes no sense. You should have a >> request object per request. It is largely a result of wanting the >> convenience of being able to write sloppy code that writes all kinds >> of state to self rather than a technical necessity. >> >> Ian > > I'd like to support Ian and Patryk's position: class based views should not > be instantiated for each request - for all the reasons Ian gave in the > quoted mail. > If you want to avoid passing around (lots of) arguments between methods, you > can always store request specific state on the request instance, which is a > common pattern for middleware already. > To prevent the request's dict from becoming too cluttered, simply put the > arguments into `request.view_context` (a dict or similar container, needs to > be painted). > > __ > Johannes > > -- > 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. > > So here's an idea, of dubious quality ;) Only pass request around to methods, and have a requests dictionary on the view (which is instantiated once) then methods can use that dict to store data in it. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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: django snippets site as a wiki
On Thu, Jun 17, 2010 at 3:39 PM, Jacob Kaplan-Moss wrote: > That said, your suggestions are sensible enough -- though personally I > think MediaWiki is a load of ... ahem .. -- so you probably should get > in touch with Charles or James (see links in the footer) and offer to > help out. That would be Charlie; djangosnippets is his baby now. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- 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?
On Thu, Jun 17, 2010 at 3:41 PM, Alex Gaynor wrote: > So here's an idea, of dubious quality ;) Okay, folks: at this point the discussion has pretty much descended into bikeshedding territory. I'm going to read through everything posted so far and try to post a summary and round-up to help us get refocused; gimme a few hours to pull that together and then let's try to reach towards a consensus. 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-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.
transaction.commit_manually masks uncaught exception
I wanted to offer an enhancement that would make transaction.commit_manually much friendlier to work with. I only offer it after banging my head on the wall for several hours. The problem is that transaction.commit_manually() masks any uncaught exception within the view it decorates. This made me lose a lot of hair today. I found a ticket addressing this problem, and have updated it: http://code.djangoproject.com/ticket/13265 I also even found some old discussion in this group from a cross- poster experiencing the problem: http://bit.ly/9KqDNA Let me know if I can help in any way. Thanks for your time. -JohnO -- 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.
