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
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
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
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
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
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
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
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
>
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
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,
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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:
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/
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
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:
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:
>
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
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
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
>
> 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
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
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...@
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
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
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
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
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
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
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
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
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
> > _
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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(
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
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
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
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
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
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
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
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-
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 *
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
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
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
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
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.
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
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
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
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
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
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.
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
> 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
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!
>
> 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__
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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 - 100 of 104 matches
Mail list logo