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

2010-10-13 Thread Roald de Vries
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 - Insta

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

2010-10-05 Thread Russell Keith-Magee
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 can do a pull from djan

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

2010-10-05 Thread Ben Firshman
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 s

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

2010-10-05 Thread Luke Plant
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 th

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

2010-10-05 Thread Ben Firshman
Sorry if this is a double post - I think Google Groups gobbling up my messages as spam or something. 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 prob

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

2010-10-05 Thread Luke Plant
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 did

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

2010-10-05 Thread legutierr
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 > really "get" PUT very we

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

2010-10-05 Thread Łukasz Rekucki
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 branch, and do they ask for any features that >

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

2010-10-05 Thread David Larlet
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 certainly yes :) We could *re

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

2010-10-05 Thread legutierr
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), and do it early > > on,

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

2010-10-05 Thread Luke Plant
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 admindocs

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

2010-10-05 Thread Andy McKay
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 way

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

2010-10-05 Thread Jacob Kaplan-Moss
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 good so far. One point of

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

2010-10-05 Thread Russell Keith-Magee
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 variation :-) You actually >> *call* the classmethod

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

2010-10-04 Thread Russell Keith-Magee
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 > arguments to it: > > url(r

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

2010-10-04 Thread Russell Keith-Magee
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 base View class, can't we >> > omit it from the urlconf and have the URLresolv

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

2010-10-04 Thread George Sakkis
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: > > >  if isinstance(view, type) and issubclass(view, View)

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

2010-10-04 Thread Marco Chomut
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 y

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

2010-10-04 Thread David P. Novakovic
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 Russ mentioned this one ca

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

2010-10-04 Thread George Sakkis
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 it: > > url(r'^detail/auth

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

2010-10-04 Thread George Sakkis
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 > > results in some other class, why not simply go

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

2010-10-04 Thread Luke Plant
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+)/$', views.AuthorDetail.as_view(so

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

2010-10-04 Thread Łukasz Rekucki
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 class, why not simply go with

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

2010-10-04 Thread Łukasz Rekucki
On 4 October 2010 19:44, Luke Plant wrote: > 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: > > http://bitbu

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

2010-10-04 Thread Luke Plant
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

2010-10-04 Thread Luke Plant
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: http://bitbucket.org/spookylukey/django-class-views-experiments/src/

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

2010-10-04 Thread Łukasz Rekucki
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 >> results in some other class, why not simply g

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

2010-10-04 Thread Luke Plant
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

2010-10-04 Thread Jacob Kaplan-Moss
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 > classmethod.  Simply used as: >

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

2010-10-04 Thread Alex Gaynor
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 rendering), and do it ear

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

2010-10-04 Thread Andrew Godwin
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), and do it early on, at a high level, inside dispatch(). Instead of expecting

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

2010-10-04 Thread legutierr
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 we've got that sorted out

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

2010-10-04 Thread Warren Smith
> > 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 set of > generic views w

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

2010-10-04 Thread Andrew Godwin
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 subclassa

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

2010-10-03 Thread André Eriksson
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 django-develop...@

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

2010-10-03 Thread André Eriksson
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 best" camp and think > > that storing some state on the request and some on

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

2010-10-03 Thread André Eriksson
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 best" camp and think > > that storing some state on the request and some on

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

2010-10-03 Thread Ian Lewis
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. >> >> http://code.google.com/appengine/docs/python/gettingstarted/handlingf

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

2010-10-03 Thread Ian Lewis
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 > singleton view instance here - just a pro

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

2010-10-03 Thread George Sakkis
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, > >> introducing the potentially un-threadsafe be

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

2010-10-03 Thread George Sakkis
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... > > Flask seems to do i

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

2010-10-03 Thread Russell Keith-Magee
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 a bit > gross, I understand Russell's argument

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

2010-10-03 Thread Russell Keith-Magee
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 urls.py: > >  (r'^somepath', with_args(MyView, option=False

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

2010-10-03 Thread Waldemar Kornewald
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 discouraging people from using arguments to > > _

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

2010-10-03 Thread Ł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 singleton view instance here - just a proxy, that imports a function on first

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

2010-10-03 Thread Łukasz Rekucki
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 Keith-Magee wrote: > >>   3) How do we make this shared settings immutable between re

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

2010-10-02 Thread Ian Lewis
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, raising >> an error on ass

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

2010-10-02 Thread David P. Novakovic
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 wh

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

2010-10-02 Thread Russell Keith-Magee
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 important questions are: > >   1) Do View instances need to share anything ? I say: yes. Agree

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

2010-10-02 Thread Russell Keith-Magee
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 that > thread, the summary saved me a whole lot of t

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

2010-10-02 Thread Russell Keith-Magee
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 of >> copy on call that will fail in non-thread sa

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

2010-10-02 Thread Patryk Zawadzki
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 that >> differentiate them from other objects o

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

2010-10-02 Thread Ł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: >>> >>> 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 t

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

2010-10-02 Thread George Sakkis
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 thread. The only argument a

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

2010-10-02 Thread Vinay Sajip
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 user of a view instance fr

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

2010-10-02 Thread Luke Plant
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 thread. The only argument against is "it's > unusual to have a class whe

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

2010-10-02 Thread George Sakkis
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 that thread, the summary saved me a whole lot of time. > I'd like to try and get this in for 1.3. It's a big featur

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

2010-10-02 Thread André Eriksson
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 opt-in. > > There's also the

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

2010-10-02 Thread Luke Plant
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 = self.dispatch(

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

2010-10-02 Thread Vince Veselosky
I've been keeping up with this thread but have not had the time to respond until now. I will endeavor to keep it brief as this thread has grown quite long! +1 on using a single dispatch() method rather than hard-coding HTTP method dispatch. As was pointed out, there are many possible dispatch patt

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

2010-10-02 Thread Carl Meyer
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 that the move to class-based

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

2010-10-02 Thread Russell Keith-Magee
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 Python class >> in existence. And as soon as the

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

2010-10-02 Thread Patryk Zawadzki
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, send email to django-devel

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

2010-10-02 Thread Patryk Zawadzki
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 > will break, in unpredicta

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

2010-10-02 Thread Russell Keith-Magee
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 >>> wrote: Could you (or anyone knowledgable) add a section, that explains why each

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

2010-10-02 Thread Russell Keith-Magee
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 idiom, but it strikes me as less fundamentally >> c

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

2010-10-02 Thread Patryk Zawadzki
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 explains why each >>> request should have its own view instance? >>> The thread-

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

2010-10-02 Thread Ł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 idiom, but it strikes me as less fundamentally > counterintuitive than prohibiting *

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

2010-10-02 Thread Russell Keith-Magee
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: > > Yes. > >>   * when it fails, it will fail during d

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

2010-10-01 Thread Carl Meyer
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 > >   * the cases where it wil

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

2010-10-01 Thread Ian Lewis
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 > sense to me at all. It remin

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

2010-10-01 Thread David P. Novakovic
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 >> override parts of the behavior without needi

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

2010-10-01 Thread Ian Lewis
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, or add 101 parameters.

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

2010-10-01 Thread Russell Keith-Magee
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 >> *required* in order to use stateless class-base

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

2010-10-01 Thread David P. Novakovic
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 expectati

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

2010-10-01 Thread Russell Keith-Magee
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 am.. > but couldn't the re

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

2010-10-01 Thread David P. Novakovic
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 with something that could

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

2010-10-01 Thread David P. Novakovic
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 pass

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

2010-10-01 Thread Vinay Sajip
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 > describe. > > Objects have state.

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

2010-10-01 Thread Johannes Dollinger
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

2010-10-01 Thread Santiago Perez
> 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()', bu

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

2010-10-01 Thread Luke Plant
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 state!

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

2010-10-01 Thread Santiago Perez
> > 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

2010-10-01 Thread 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 from > interested > > parties are welcome. Try to

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

2010-10-01 Thread Andrew Godwin
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

2010-10-01 Thread Russell Keith-Magee
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 Keith-Magee: I've just added a summary of the last thread on class-b

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

2010-10-01 Thread Brandon Konkle
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

2010-10-01 Thread Alex Gaynor
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 [1]. >>> This summary isn't 100% complete -- any c

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

2010-10-01 Thread Russell Keith-Magee
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 [1]. >> This summary isn't 100% complete -- any contributions from interested >> parties are welcome. Try to keep opi

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

2010-10-01 Thread Tobias McNulty
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. Fundamentally we need > to have a little faith in yo

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

2010-10-01 Thread Russell Keith-Magee
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 requires that all view logic is contained in GET()

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

2010-10-01 Thread Russell Keith-Magee
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 proposing to maintain backw

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

2010-10-01 Thread Russell Keith-Magee
On Fri, Oct 1, 2010 at 6:46 PM, burc...@gmail.com wrote: > Hi Russell, > > Few more questions I haven't seen answers yet. > > How should urls() work for such views? Should they? Erm... no. A view doesn't have a collection of URLs. A view is a view. What we're debating here is a way to construct g

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

2010-10-01 Thread Alex Gaynor
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 argument alone does not suffice: if all _request_ st

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

2010-10-01 Thread Vinay Sajip
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 instead of the view, you

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

2010-10-01 Thread Ben Firshman
I don't think we should worry about documentation nightmares - we could leave most of it undocumented and just expose the bits which look like the current generic views (and a few base views) as the public API. I have added a "how to help" section to the wiki page: http://code.djangoproject.com

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

2010-10-01 Thread Johannes Dollinger
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 strengt

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

2010-10-01 Thread Andrew Godwin
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

2010-10-01 Thread burc...@gmail.com
Hi Russell, Few more questions I haven't seen answers yet. How should urls() work for such views? Should they? How can self.redirect_to() get current app, namespace and function name to work if one should use reverse() ? How should request should be passed for self.render()? Implicitly or explici

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

2010-10-01 Thread David Larlet
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 variou

  1   2   >