> For a 404 you should still be able to just raise the exception, for other
> response you could create your own Exception like ResponseIsReady and just
> raise it and have __init__ return as soon as it's done.
I though about this, but isn't raising an exception to provoke not
really an exception
2009/5/20 Filip Gruszczyński
>
> Yeah, I did a quick check in the interpreter and this is indeed very cool.
>
> There is another thing though that worries me (but just a little).
> Often, when I write views, it's nice to be able just to return 404 or
> 302 at any moment and not proceed with a cur
Yeah, I did a quick check in the interpreter and this is indeed very cool.
There is another thing though that worries me (but just a little).
Often, when I write views, it's nice to be able just to return 404 or
302 at any moment and not proceed with a current function. For 404 it
can be always d
2009/5/20 Filip Gruszczyński
>
> > Take a look at this:
> http://code.djangoproject.com/ticket/6735#comment:37
> > snippet which actually does let you store state on the object.
>
> The suggested solution is very cool, but I wonder, how to change
> status code of such responses. status_code is a
> Take a look at this: http://code.djangoproject.com/ticket/6735#comment:37
> snippet which actually does let you store state on the object.
The suggested solution is very cool, but I wonder, how to change
status code of such responses. status_code is a class attribute, so if
while serving a requ
2009/5/20 Filip Gruszczyński
>
> > I don't have major beefs with your solution, but I'll offer a few
> > alternatives that might accomplish the same thing, without creating
> > inheritance. Inheritance feels a little heavy for what you're trying
> > to provide, which is basically just a common m
> I don't have major beefs with your solution, but I'll offer a few
> alternatives that might accomplish the same thing, without creating
> inheritance. Inheritance feels a little heavy for what you're trying
> to provide, which is basically just a common method to tie together
> three other meth
On May 20, 6:33 am, Filip Gruszczyński wrote:
>
> I have recently created a class:
>
> class RequestService:
>
> def __call__(self, request, *args, **kwargs):
> self.prepare(request, *args, **kwargs)
> if request.method == 'POST':
>
> One thing to keep in mind is that the object is shared across all requests
> in that process, so you can't actually store state on your object.
What exactly do you mean? Because I just got very worried.
I have a class like this:
class CreateAddressService(RequestService):
def
2009/5/20 Brian Neal
>
> On May 20, 8:33 am, Filip Gruszczyński wrote:
> > I was wondering: have you considered using some callable objects to
> > serve requests in views.py instead of functions?
>
> Sure, check out this blog post (not the only example):
>
>
> http://www.screeley.com/entries/200
On May 20, 8:33 am, Filip Gruszczyński wrote:
> I was wondering: have you considered using some callable objects to
> serve requests in views.py instead of functions?
Sure, check out this blog post (not the only example):
http://www.screeley.com/entries/2009/apr/01/class-based-views-and-reusabl
11 matches
Mail list logo
