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 l
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
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 woul
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). On
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
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
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
sni
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, **
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-saf
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
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 view
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 some
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<
>>
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 cl
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. Th
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=
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
>
> 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 th
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, whe
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
implement
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 deco
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
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
>
> 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 Boo
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:
>
> fo
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 als
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 se
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 me
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
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 develo
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 me
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?
W
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 the
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 m
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 def
35 matches
Mail list logo
