Re: #6735 -- Class based generic views: call for comment

Hi Ben, I like your implementation, but I don't really like the class name 'View'; I would opt for 'Resource' (or 'ResourceHandle'). Why I don't like 'View': - It's a very abstract thing, it's conceptually defined as 'the thing that maps a request to a response', or something alike -

Re: #6735 -- Class based generic views: call for comment

On Wed, Oct 6, 2010 at 8:33 AM, Luke Plant wrote: > On Tue, 2010-10-05 at 22:29 +0100, I wrote: > >> Russell - beware - I think bitbucket has managed to create a very broken >> clone. I did a fork as well, and both of our repositories are missing >> thousands of commits.  I

Re: #6735 -- Class based generic views: call for comment

Thanks to everyone who's helping push this forward. I would get stuck in, but I'm bogged down with work at the moment. A couple of things from the wiki page that need doing: 1) Test coverage probably isn't great. Everything seems to work when I've used it in applications, but there's probably

Re: #6735 -- Class based generic views: call for comment

On Tue, 2010-10-05 at 22:29 +0100, I wrote: > Russell - beware - I think bitbucket has managed to create a very broken > clone. I did a fork as well, and both of our repositories are missing > thousands of commits. I can do a pull from django/django and I then get > a complete repository which

Re: #6735 -- Class based generic views: call for comment

On Tue, 2010-10-05 at 21:03 +0800, Russell Keith-Magee wrote: > Ok - so to kick the process into the next phase, I've just created a > Django branch in my bitbucket repo [1] to cover introducing this to > trunk. Russell - beware - I think bitbucket has managed to create a very broken clone. I

Re: #6735 -- Class based generic views: call for comment

On Oct 5, 10:43 am, Jacob Kaplan-Moss wrote: > >  * Does django.views.generic.utils.coerce_put_post() indicate a change > > that needs to be made in Django? (Is there an existing ticket for > > this?) > > Yeah, this has been a wart in Django for a while -- Django doesn't >

Re: #6735 -- Class based generic views: call for comment

On 5 October 2010 22:10, David Larlet wrote: > > > Jacob Kaplan-Moss a écrit : >> >> On Tue, Oct 5, 2010 at 8:03 AM, Russell Keith-Magee >>  wrote: >>> >>>  * Are there any outstanding tickets on generic views that will be >>> closed by merging this

Re: #6735 -- Class based generic views: call for comment

Jacob Kaplan-Moss a écrit : On Tue, Oct 5, 2010 at 8:03 AM, Russell Keith-Magee wrote: * Are there any outstanding tickets on generic views that will be closed by merging this branch, and do they ask for any features that aren't fixed by this branch? Almost

Re: #6735 -- Class based generic views: call for comment

On Oct 4, 1:04 pm, Andrew Godwin wrote: > On 04/10/10 17:28, legutierr wrote: > > >    * First, treat data processing and retrieval as separable from > > rendering.  Create a bright line of separation between the two > > conceptual elements of the view (data and rendering),

Re: #6735 -- Class based generic views: call for comment

On Tue, 2010-10-05 at 09:43 -0500, Jacob Kaplan-Moss wrote: > One point of concern that came up though: looking at the way as_view > introduces a closure, it occurs to me that the docstring of am > as_view'd class view isn't very useful, which'll break introspection > and things like the

Re: #6735 -- Class based generic views: call for comment

On 2010-10-01, at 3:57 PM, David P. Novakovic wrote: > I may be missing something obvious here, so please tell me if I am.. > but couldn't the resolver just check that quacks like something > OOViewish has been passed in and simply branch and init the class > before calling the view in the same

Re: #6735 -- Class based generic views: call for comment

On Tue, Oct 5, 2010 at 8:03 AM, Russell Keith-Magee wrote: > Ok - so to kick the process into the next phase, I've just created a > Django branch in my bitbucket repo [1] to cover introducing this to > trunk. I gave this a quick review and nothing huge jumped out. Looks

Re: #6735 -- Class based generic views: call for comment

On Tue, Oct 5, 2010 at 12:59 PM, Russell Keith-Magee wrote: > On Tue, Oct 5, 2010 at 3:16 AM, Luke Plant wrote: >> On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: >> >>> Last idea, I swear, >> >> I didn't swear, so here is another slight

Re: #6735 -- Class based generic views: call for comment

On Tue, Oct 5, 2010 at 3:16 AM, Luke Plant wrote: > On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > >> Last idea, I swear, > > I didn't swear, so here is another slight variation :-) You actually > *call* the classmethod in your URLconf, passing any constructor >

Re: #6735 -- Class based generic views: call for comment

On Tue, Oct 5, 2010 at 5:43 AM, George Sakkis wrote: > On Oct 4, 10:55 pm, "David P. Novakovic" > wrote: >> On Tue, Oct 5, 2010 at 5:21 AM, George Sakkis >> wrote: >> >> > Since dispatch is going to be defined on the

Re: #6735 -- Class based generic views: call for comment

On Oct 4, 10:55 pm, "David P. Novakovic" wrote: > On Tue, Oct 5, 2010 at 5:21 AM, George Sakkis wrote: > > > Since dispatch is going to be defined on the base View class, can't we > > omit it from the urlconf and have the URLresolver do: > > >  

Re: #6735 -- Class based generic views: call for comment

I agree with George, and would like to not have to write the dispatch out every time, but my only concern is how confusing an implicit dispatch would be for developers first using the new class-based Views system. As long as it was made abundantly clear via the docs what exactly is happening when

Re: #6735 -- Class based generic views: call for comment

On Tue, Oct 5, 2010 at 5:21 AM, George Sakkis wrote: > > Since dispatch is going to be defined on the base View class, can't we > omit it from the urlconf and have the URLresolver do: > >  if isinstance(view, type) and issubclass(view, View): >      view = view.dispatch

Re: #6735 -- Class based generic views: call for comment

On Oct 4, 9:16 pm, Luke Plant wrote: > On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > > Last idea, I swear, > > I didn't swear, so here is another slight variation :-) You actually > *call* the classmethod in your URLconf, passing any constructor > arguments to

Re: #6735 -- Class based generic views: call for comment

On Oct 4, 7:22 pm, Jacob Kaplan-Moss wrote: > On Mon, Oct 4, 2010 at 12:08 PM, Alex Gaynor wrote: > > Given that the primary complain against the __new__ solution is that > > it's unintuitive to Python programmers that instantiating their class > >

Re: #6735 -- Class based generic views: call for comment

On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > Last idea, I swear, I didn't swear, so here is another slight variation :-) You actually *call* the classmethod in your URLconf, passing any constructor arguments to it: url(r'^detail/author/(?P\d+)/$',

Re: #6735 -- Class based generic views: call for comment

On 4 October 2010 20:03, Luke Plant wrote: > On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: >> Given that the primary complain against the __new__ solution is that >> it's unintuitive to Python programmers that instantiating their class >> results in some other

Re: #6735 -- Class based generic views: call for comment

On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > Given that the primary complain against the __new__ solution is that > it's unintuitive to Python programmers that instantiating their class > results in some other class, why not simply go with a more explicit > classmethod. Simply used as:

Re: #6735 -- Class based generic views: call for comment

On Mon, 2010-10-04 at 19:37 +0200, Łukasz Rekucki wrote: > The only problem is decorators: You can't just simply apply > login_required() to the class or the dispatch() method. Otherwise, I > like this approach. It works fine:

Re: #6735 -- Class based generic views: call for comment

On 4 October 2010 19:22, Jacob Kaplan-Moss wrote: > On Mon, Oct 4, 2010 at 12:08 PM, Alex Gaynor wrote: >> Given that the primary complain against the __new__ solution is that >> it's unintuitive to Python programmers that instantiating their class >>

Re: #6735 -- Class based generic views: call for comment

On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > Given that the primary complain against the __new__ solution is that > it's unintuitive to Python programmers that instantiating their class > results in some other class, why not simply go with a more explicit > classmethod. Simply used

Re: #6735 -- Class based generic views: call for comment

On Mon, Oct 4, 2010 at 12:08 PM, Alex Gaynor wrote: > Given that the primary complain against the __new__ solution is that > it's unintuitive to Python programmers that instantiating their class > results in some other class, why not simply go with a more explicit >

Re: #6735 -- Class based generic views: call for comment

On Mon, Oct 4, 2010 at 1:04 PM, Andrew Godwin wrote: > On 04/10/10 17:28, legutierr wrote: >> >>   * First, treat data processing and retrieval as separable from >> rendering.  Create a bright line of separation between the two >> conceptual elements of the view (data and

Re: #6735 -- Class based generic views: call for comment

On Oct 2, 10:32 pm, Russell Keith-Magee wrote: > I completely agree that we don't want to rush this. The upside is that > if we *can* reach consensus, it isn't going to require a whole lot of > code changes; We're arguing about how to architect the base class, but > once

Re: #6735 -- Class based generic views: call for comment

> > On Mon, Oct 4, 2010 at 8:08 AM, Andrew Godwin wrote: > > I'd just like to add more noise to the signal and reiterate this - storing > state on self (or request) leads to much cleaner, less fragile, more > subclassable views (in my own experience, having written both a

Re: #6735 -- Class based generic views: call for comment

On 03/10/10 03:20, Russell Keith-Magee wrote: * Ignore the legitimate occasions where using state is a useful architectural approach. I'd just like to add more noise to the signal and reiterate this - storing state on self (or request) leads to much cleaner, less fragile, more

Re: #6735 -- Class based generic views: call for comment

I should add.. The bonus of using class-based decorators is that decorated views can be subclassed. All other functionality is retained. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: #6735 -- Class based generic views: call for comment

On Oct 3, 1:02 pm, Russell Keith-Magee wrote: > On Sun, Oct 3, 2010 at 12:12 PM, Ian Lewis wrote: > > On Sun, Oct 3, 2010 at 11:20 AM, Russell Keith-Magee > > wrote: > > While I'm in the "one singleton view instance is

Re: #6735 -- Class based generic views: call for comment

On Sun, Oct 3, 2010 at 8:02 PM, Russell Keith-Magee wrote: >> 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. >> >>

Re: #6735 -- Class based generic views: call for comment

2010/10/3 Łukasz Rekucki : > On 3 October 2010 06:12, Ian Lewis wrote: >> Flask seems to do it the callable singleton way: >> >> http://flask.pocoo.org/docs/patterns/lazyloading/ >> > I never used Flask, so I might be missing something, but I don't see a >

Re: #6735 -- Class based generic views: call for comment

On Oct 3, 4:20 am, Russell Keith-Magee wrote: > On Sat, Oct 2, 2010 at 8:01 PM, Carl Meyer wrote: > >> We could even wrap the "no args to __init__" error check in a method > >> that enables it to be overridden and silenced in a subclass; that way,

Re: #6735 -- Class based generic views: call for comment

On Oct 3, 6:12 am, Ian Lewis wrote: > 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... >

Re: #6735 -- Class based generic views: call for comment

On Sun, Oct 3, 2010 at 12:12 PM, Ian Lewis wrote: > On Sun, Oct 3, 2010 at 11:20 AM, Russell Keith-Magee > 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

Re: #6735 -- Class based generic views: call for comment

2010/10/3 Łukasz Rekucki : > On 3 October 2010 04:44, Russell Keith-Magee wrote: >> 2010/10/3 Łukasz Rekucki : > def with_args(view_cls, **kwargs): >    return type(view_cls.__name__, (view_cls,), kwargs) > > # in

Re: #6735 -- Class based generic views: call for comment

Hi, first of all, I'd like to say that I fully agree that the final solution has to be thread-safe and has to support storing state on self. On Oct 2, 12:32 pm, Russell Keith-Magee wrote: > 2010/10/2 Łukasz Rekucki : > > Now you lost me. If we are

Re: #6735 -- Class based generic views: call for comment

On 3 October 2010 06:12, Ian Lewis wrote: > Flask seems to do it the callable singleton way: > > http://flask.pocoo.org/docs/patterns/lazyloading/ > I never used Flask, so I might be missing something, but I don't see a singleton view instance here - just a proxy, that

Re: #6735 -- Class based generic views: call for comment

On 3 October 2010 04:44, Russell Keith-Magee wrote: > 2010/10/3 Łukasz Rekucki : >> On 2 October 2010 12:32, Russell Keith-Magee wrote: >>> 2010/10/2 Łukasz Rekucki : On 2 October 2010 10:34, Russell

Re: #6735 -- Class based generic views: call for comment

On Sun, Oct 3, 2010 at 11:20 AM, Russell Keith-Magee wrote: >> The issue is not only the frequency of failure, but how explicit/clear >> it is. The failure here is so obscure and difficult to track down, it >> is likely to generate an outsize support burden. In contrast,

Re: #6735 -- Class based generic views: call for comment

Sorry, I keep top replying in my emails. It's because I'm mostly taking everything in and not really replying to anyone specifically. I _really_ like the idea of View being synonymous with a ResponseFactory. Using __call__: The view base class can take *args and **kwargs and apply them lazily

Re: #6735 -- Class based generic views: call for comment

2010/10/3 Łukasz Rekucki : > On 2 October 2010 12:32, Russell Keith-Magee wrote: >> 2010/10/2 Łukasz Rekucki : >>> On 2 October 2010 10:34, Russell Keith-Magee >>> wrote: > To sum this up, I think the

Re: #6735 -- Class based generic views: call for comment

On Sun, Oct 3, 2010 at 12:20 AM, George Sakkis wrote: > On Oct 1, 7:26 am, Russell Keith-Magee > wrote: >> >> I've just added a summary of the last thread on class-based views [1]. > > Thanks for writing this up. Having missed the discussion on

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 8:01 PM, Carl Meyer wrote: > > > On Oct 2, 4:34 am, Russell Keith-Magee > wrote: >> I can't argue with the fact that setting variables in __init__() is a >> common idiom in Python generally, and this is certainly a weakness

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 1:40 PM, Russell Keith-Magee wrote: > On Sat, Oct 2, 2010 at 7:05 PM, Patryk Zawadzki wrote: >> Classes that represent real objects have state. Like cars have color, >> make and registration number, your models have attributes

Re: #6735 -- Class based generic views: call for comment

On 2 October 2010 12:32, Russell Keith-Magee wrote: > 2010/10/2 Łukasz Rekucki : >> On 2 October 2010 10:34, Russell Keith-Magee wrote: >>> >>> Another option would be to use copy-on-call, but raise an error if >>> they

Re: #6735 -- Class based generic views: call for comment

On Oct 2, 6:46 pm, Luke Plant wrote: > On Sat, 2010-10-02 at 09:20 -0700, George Sakkis wrote: > > Having said that, I'm in favour of the first approach mentioned in the > > wiki (store state on request) and I'm surprised it doesn't seem to > > have any traction in this

Re: #6735 -- Class based generic views: call for comment

On Oct 2, 1:01 pm, Carl Meyer wrote: > Again, arguments to __init__ are not the issue. What would have to be > checked is any assignment to self that takes place in __init__. How do > you propose to check that? > I think __slots__ would do for this: it would prevent a

Re: #6735 -- Class based generic views: call for comment

On Oct 2, 12:32 pm, Russell Keith-Magee wrote: > > The difference is that __new__ doesn't *ever* allow for initialization > arguments -- there is no way to pass an argument in. An "arguments > disabled by default" __init__+copy implementation allows arguments as > an

Re: #6735 -- Class based generic views: call for comment

On Fri, 2010-10-01 at 17:31 +0100, Luke Plant wrote: > Or, more drastically, we could just do this: > > class View(object): > def __call__(self, request, *args, **kwargs): > self.request = request > self.args = args > self.kwargs = kwargs > resp =

Re: #6735 -- Class based generic views: call for comment

On Oct 2, 4:34 am, Russell Keith-Magee wrote: > I can't argue with the fact that setting variables in __init__() is a > common idiom in Python generally, and this is certainly a weakness of > copy on call that will fail in non-thread safe ways. > > My counterclaim is

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 7:05 PM, Patryk Zawadzki wrote: > On Sat, Oct 2, 2010 at 12:49 PM, Russell Keith-Magee > wrote: >> Python classes have state. People *will* assign variables to self, >> because that's something they have done with every other

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 1:05 PM, Patryk Zawadzki wrote: > But until Joey appears to give you money (...) s/until/before/ -- Patryk Zawadzki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group,

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 12:49 PM, Russell Keith-Magee wrote: > Python classes have state. People *will* assign variables to self, > because that's something they have done with every other Python class > in existence. And as soon as their code hits production, their code >

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 6:08 PM, Patryk Zawadzki wrote: > On Fri, Oct 1, 2010 at 3:55 PM, Alex Gaynor wrote: >> On Fri, Oct 1, 2010 at 9:53 AM, Vinay Sajip wrote: >>> On Oct 1, 11:16 am, Johannes Dollinger

Re: #6735 -- Class based generic views: call for comment

2010/10/2 Łukasz Rekucki : > On 2 October 2010 10:34, Russell Keith-Magee wrote: >> >> Another option would be to use copy-on-call, but raise an error if >> they provide any arguments to __init__(). This would be annoying and >> counter to Python

Re: #6735 -- Class based generic views: call for comment

On Fri, Oct 1, 2010 at 3:55 PM, Alex Gaynor wrote: > On Fri, Oct 1, 2010 at 9:53 AM, Vinay Sajip wrote: >> On Oct 1, 11:16 am, Johannes Dollinger >> wrote: >>> Could you (or anyone knowledgable) add a section, that

Re: #6735 -- Class based generic views: call for comment

On 2 October 2010 10:34, Russell Keith-Magee wrote: > > Another option would be to use copy-on-call, but raise an error if > they provide any arguments to __init__(). This would be annoying and > counter to Python idiom, but it strikes me as less fundamentally >

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 12:56 PM, Carl Meyer wrote: > > > On Oct 1, 10:00 pm, Russell Keith-Magee > wrote: >> Now, I'm sure the counterargument is going to be that copy() will be >> just as error prone and FAQ inducing. My argument to this is: > >

Re: #6735 -- Class based generic views: call for comment

On Oct 1, 10:00 pm, Russell Keith-Magee wrote: > Now, I'm sure the counterargument is going to be that copy() will be > just as error prone and FAQ inducing. My argument to this is: Yes. >   * when it fails, it will fail during development, not just in production > >  

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 11:37 AM, David P. Novakovic wrote: > By this reasoning, when you add extra helper methods to your class, > which is the reason for OO views, you need to add/use the data those > methods will modify to the request object? That just doesn't make >

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 12:26 PM, Ian Lewis wrote: > On Sat, Oct 2, 2010 at 12:20 AM, Alex Gaynor wrote: >> Not really.  The big win from a class-based view is not being able to >> store state, you can do that with local variables, it's being able to >>

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 12:20 AM, Alex Gaynor wrote: > Not really.  The big win from a class-based view is not being able to > store state, you can do that with local variables, it's being able to > override parts of the behavior without needing to rewrite the entire > view,

Re: #6735 -- Class based generic views: call for comment

On Saturday, October 2, 2010, Vinay Sajip wrote: > > On Oct 1, 4:16 pm, Russell Keith-Magee > wrote: > >> "Don't use instance variables on a class" isn't advice you're going to >> see printed very often. Yet that would be the advice that would be

Re: #6735 -- Class based generic views: call for comment

Yeah, I actually read your modification of the trac page after posting this :\ I guess what I'm getting at is the more general issue of maintaining the same interface... is it really that important? If people acknowledge that they are using a different system, then they can adjust their

Re: #6735 -- Class based generic views: call for comment

On Saturday, October 2, 2010, David P. Novakovic wrote: > My problem with all of this is that it feels like a hell of a lot of > hoopjumping to deal with something that could be solved in the > Resolver. > > I may be missing something obvious here, so please tell me if I

Re: #6735 -- Class based generic views: call for comment

Sorry in my previous email you could simply pass the uninstantiated class in the url pattern. url(r'...',MyOOView,...) On Sat, Oct 2, 2010 at 8:57 AM, David P. Novakovic wrote: > My problem with all of this is that it feels like a hell of a lot of > hoopjumping to deal

Re: #6735 -- Class based generic views: call for comment

My problem with all of this is that it feels like a hell of a lot of hoopjumping to deal with something that could be solved in the Resolver. I may be missing something obvious here, so please tell me if I am.. but couldn't the resolver just check that quacks like something OOViewish has been

Re: #6735 -- Class based generic views: call for comment

On Oct 1, 4:16 pm, Russell Keith-Magee wrote: > "Don't use instance variables on a class" isn't advice you're going to > see printed very often. Yet that would be the advice that would be > *required* in order to use stateless class-based views in the way you >

Re: #6735 -- Class based generic views: call for comment

Am 01.10.2010 um 18:07 schrieb Luke Plant: > On Fri, 2010-10-01 at 12:16 +0200, Johannes Dollinger wrote: >> Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee: >>> I've just added a summary of the last thread on class-based views >> [1]. >>> This summary isn't 100% complete -- any contributions

Re: #6735 -- Class based generic views: call for comment

> This would kill the ability to use __init__ to store anything on the > instance, since it would only work for the first request, and so would > enforce subclassing as the only means of customising behaviour. It would > be more effective at dealing with thread safety concerns than a > 'copy()',

Re: #6735 -- Class based generic views: call for comment

Or, more drastically, we could just do this: class View(object): def __call__(self, request, *args, **kwargs): self.request = request self.args = args self.kwargs = kwargs resp = self.dispatch(request, *args, **kwargs) self.__dict__ = {} # goodbye

Re: #6735 -- Class based generic views: call for comment

> > We document the issue, warn people not to store state on the instance > itself, but tell them that if they must have stateful data, it should be > attached to self.state instead of self, and they will be OK. They might > still be bitten if they put mutable configuration data into the __init__

Re: #6735 -- Class based generic views: call for comment

On Fri, 2010-10-01 at 12:16 +0200, Johannes Dollinger wrote: > Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee: > > I've just added a summary of the last thread on class-based views > [1]. > > This summary isn't 100% complete -- any contributions from > interested > > parties are welcome. Try

Re: #6735 -- Class based generic views: call for comment

On 01/10/10 16:25, Brandon Konkle wrote: On Oct 1, 2010, at 10:20 AM, Alex Gaynor wrote: Not really. The big win from a class-based view is not being able to store state, you can do that with local variables, it's being able to override parts of the behavior without needing to rewrite the

Re: #6735 -- Class based generic views: call for comment

On Fri, Oct 1, 2010 at 11:20 PM, Alex Gaynor wrote: > On Fri, Oct 1, 2010 at 11:16 AM, Russell Keith-Magee > wrote: >> On Fri, Oct 1, 2010 at 6:16 PM, Johannes Dollinger >> wrote: >>> Am 01.10.2010 um 07:26 schrieb Russell

Re: #6735 -- Class based generic views: call for comment

On Oct 1, 2010, at 10:20 AM, Alex Gaynor wrote: > Not really. The big win from a class-based view is not being able to > store state, you can do that with local variables, it's being able to > override parts of the behavior without needing to rewrite the entire > view, or add 101 parameters. If

Re: #6735 -- Class based generic views: call for comment

On Fri, Oct 1, 2010 at 11:16 AM, Russell Keith-Magee wrote: > On Fri, Oct 1, 2010 at 6:16 PM, Johannes Dollinger > wrote: >> Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee: >>> I've just added a summary of the last thread on class-based views

Re: #6735 -- Class based generic views: call for comment

On Fri, Oct 1, 2010 at 9:55 AM, Alex Gaynor wrote: > On Fri, Oct 1, 2010 at 9:53 AM, Vinay Sajip > wrote: > > It seems better to stress thread-safety dos and don'ts in the > > documentation. > > Without wanting to beat a dead horse, I concur.

Re: #6735 -- Class based generic views: call for comment

On Fri, Oct 1, 2010 at 6:17 PM, Luke Plant wrote: > On Fri, 2010-10-01 at 11:12 +0200, Hanne Moa wrote: >> On 1 October 2010 07:26, Russell Keith-Magee wrote: >> > I already have one specific piece of API feedback: the current >> > implementation

Re: #6735 -- Class based generic views: call for comment

On Fri, Oct 1, 2010 at 6:42 PM, David Larlet wrote: > > Russell Keith-Magee a écrit : > >>  * Conversion of the github project into a patch on trunk. > > Do you see that as a total replacement of actual views.generic or should we > go for a old/new dance? Unless you're

Re: #6735 -- Class based generic views: call for comment

On Fri, Oct 1, 2010 at 9:53 AM, Vinay Sajip wrote: > On Oct 1, 11:16 am, Johannes Dollinger > wrote: >> Could you (or anyone knowledgable) add a section, that explains why each >> request should have its own view instance? >> The thread-safety

Re: #6735 -- Class based generic views: call for comment

On Oct 1, 11:16 am, Johannes Dollinger wrote: > Could you (or anyone knowledgable) add a section, that explains why each > request should have its own view instance? > The thread-safety argument alone does not suffice: if all _request_ state > would be stored on request

Re: #6735 -- Class based generic views: call for comment

Am 01.10.2010 um 07:26 schrieb Russell Keith-Magee: > I've just added a summary of the last thread on class-based views [1]. > This summary isn't 100% complete -- any contributions from interested > parties are welcome. Try to keep opinions to a minimum; this page is > about documenting the

Re: #6735 -- Class based generic views: call for comment

On 01/10/10 11:17, Luke Plant wrote: Passing things around between '_common' and GET and POST makes a simple view much more complex than it needs to be, especially when you have various local variables that you now have to assign in some way. In the end you will end up just routing it all to the

Re: #6735 -- Class based generic views: call for comment

Russell Keith-Magee a écrit : I've just added a summary of the last thread on class-based views [1]. This summary isn't 100% complete -- any contributions from interested parties are welcome. Try to keep opinions to a minimum; this page is about documenting the strengths and weaknesses of

Re: #6735 -- Class based generic views: call for comment

On 1 October 2010 07:26, Russell Keith-Magee wrote: > I already have one specific piece of API feedback: the current > implementation requires that all view logic is contained in GET(), > POST() etc style views. This is fine, except for the fact that there > are occasions

Re: #6735 -- Class based generic views: call for comment

> > I already have one specific piece of API feedback: the current > implementation requires that all view logic is contained in GET(), > POST() etc style views. This is fine, except for the fact that there > are occasions where GET and POST share a lot of common logic. It would > make sense to me

#6735 -- Class based generic views: call for comment

Hi all, I've just added a summary of the last thread on class-based views [1]. This summary isn't 100% complete -- any contributions from interested parties are welcome. Try to keep opinions to a minimum; this page is about documenting the strengths and weaknesses of various approaches, not about