Re: Raising Http Redirect
Given that I've thought a bit about this not too long ago[1], I'll pipe in with my little bit of philosophy, along with some advice on the topic at hand. Exceptions are, by definition, exceptional. They defy the rule. That could mean errors, but it could also mean any other situation that a particular rule doesn't account for. Ultimately, you can only define exceptions with regard to the rules they defy, and the rules followed by a piece of code are dictated entirely by the developer of that code. If you don't want your flow to accommodate a situation, you're welcome to raise an exception and have other code handle that case. However, in the case of Django, the framework itself can't possibly accommodate everyone's idea of how rules should be written. Instead, it has to take a middle-of-the-road approach, trying to cover the most common situations, while allowing other situations to be handled easily. Clearly having an exception for redirects won't be necessary (or even good) for most Django users, so it's not something that will make it into the framework itself. Especially since, as has already been mentioned on this thread, it's quite possible to accomplish with middleware. If, however, you'd like to see the existing HTTP exceptions refactored in such a way that you could subclass them to create a redirecting exception without the middleware, that's an entirely separate issue, and one that would probably be better received. It still might not make it into trunk, but I would think that it would be a much better suggestion than "I'm doing non-standard practice X, can it be added to Django so I can save myself a dozen (or less!) lines of code?" I'd recommend creating a ticket for generalizing HTTP exceptions so that the exception class can dictate what response gets sent. But don't expect me to implement it. -Gul [1] http://gulopine.gamemusic.org/2007/nov/21/except-the-unexpected/ (Sorry if the page loads slowly or not at all, the server's having issues) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Raising Http Redirect
Hi, On Wed, Jan 02, 2008 at 09:35:33AM -0600, James Bennett wrote: > On Jan 2, 2008 8:20 AM, Forest Bond <[EMAIL PROTECTED]> wrote: > > I disagree. Exceptions represent "exceptional situations," not all of > > which are > > necessarily errors. For instance, SystemExit is not really an error, is it? > > What about StopIteration? > > By that analogy as well, exceptions would be the wrong choice here: > what's "exceptional" about returning a redirect? A 404 or 500 is > exceptional -- it's something outside of otherwise-routine operation. > But redirecting from one page to another *is* a part of routine > operation. StopIteration represents a routine action: the end of a loop. What is exceptional about it is the interruption in flow, much like a redirection can be thought of as an interruption in content generation (in a view). An exception means "stop what you're doing and deal with this new condition." This is probably a pointless argument, though. Clearly, you prefer to use exceptions exclusively for error conditions, and I don't mind (ab)using them for other purposes as well. I view exceptions as a more general message-passing mechanism with some advantageous properties, not just a red flag to throw when things go sour. I wouldn't use them for everything, but they do lend themselves to some "stop that and do this instead" situations. -Forest -- Forest Bond http://www.alittletooquiet.net signature.asc Description: Digital signature
Re: Raising Http Redirect
On Jan 2, 2008 9:37 AM, Thomas Guettler <[EMAIL PROTECTED]> wrote: > If someone tries to save a form, but someone else was faster, > then I want to leave the slower person a message, and redirect him to > the form again. His changes will be lost. Why not return a validation error from the form telling the user what's happening, instead of silently throwing away their work? ;) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Raising Http Redirect
On Jan 2, 2008 8:20 AM, Forest Bond <[EMAIL PROTECTED]> wrote: > I disagree. Exceptions represent "exceptional situations," not all of which > are > necessarily errors. For instance, SystemExit is not really an error, is it? > What about StopIteration? By that analogy as well, exceptions would be the wrong choice here: what's "exceptional" about returning a redirect? A 404 or 500 is exceptional -- it's something outside of otherwise-routine operation. But redirecting from one page to another *is* a part of routine operation. So, again, I'm against this. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Raising Http Redirect
Am Mittwoch, 2. Januar 2008 11:09 schrieb James Bennett: > On Jan 2, 2008 3:49 AM, Thomas Guettler <[EMAIL PROTECTED]> wrote: > > The HTTP return codes 404 and 500 can be raised with an exception. > > > > That's very handy. Unfortunately a Http Redirect can't be raised. > > Do other django users thing this would be usefull, too? > > No. Exceptions represent "errors" in a program, and the 4xx and 5xx > status codes represent "errors" in HTTP, so that maps well. But 3xx > status codes in HTTP are not errors, so implementing them as > exceptions would feel awfully strange. Hi James, in my case this redirect exception is a kind of error. But it is not an error at http level. My usecase: The model MyModel has an attribute mtime. Everytime someone edits it, the mtime gets updated. The form to edit the Model has a hidden input with the mtime. If someone tries to save a form, but someone else was faster, then I want to leave the slower person a message, and redirect him to the form again. His changes will be lost. without exception: response=obj.check_mtime(request) if response: return response with exception: obj.check_mtime(request) Since the code will be written several times, I prefere the one line solution. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Raising Http Redirect
On Wed, Jan 02, 2008 at 04:09:43AM -0600, James Bennett wrote: > > On Jan 2, 2008 3:49 AM, Thomas Guettler <[EMAIL PROTECTED]> wrote: > > The HTTP return codes 404 and 500 can be raised with an exception. > > > > That's very handy. Unfortunately a Http Redirect can't be raised. > > Do other django users thing this would be usefull, too? > > No. Exceptions represent "errors" in a program, and the 4xx and 5xx > status codes represent "errors" in HTTP, so that maps well. But 3xx > status codes in HTTP are not errors, so implementing them as > exceptions would feel awfully strange. I disagree. Exceptions represent "exceptional situations," not all of which are necessarily errors. For instance, SystemExit is not really an error, is it? What about StopIteration? The "error condition" semantics of exceptions are injected. More practically, in Python, exceptions provide a simple way to trigger a major state change in the application from a lower level in the call stack. This is frequently not an error. A redirection exception seems natural to me; I've implemented something like this myself in the past. -Forest -- Forest Bond http://www.alittletooquiet.net signature.asc Description: Digital signature
Re: Raising Http Redirect
On Jan 2, 2008 3:49 AM, Thomas Guettler <[EMAIL PROTECTED]> wrote: > The HTTP return codes 404 and 500 can be raised with an exception. > > That's very handy. Unfortunately a Http Redirect can't be raised. > Do other django users thing this would be usefull, too? No. Exceptions represent "errors" in a program, and the 4xx and 5xx status codes represent "errors" in HTTP, so that maps well. But 3xx status codes in HTTP are not errors, so implementing them as exceptions would feel awfully strange. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Raising Http Redirect
Hi, The HTTP return codes 404 and 500 can be raised with an exception. That's very handy. Unfortunately a Http Redirect can't be raised. Do other django users thing this would be usefull, too? I implemented it myself. But I think something like this should be in django. #responseutils.py class HttpRedirectException(Exception): pass # middleware.py def process_exception(self, request, exception): if isinstance(exception, responseutils.HttpRedirectException): return django.http.HttpResponseRedirect(exception.args[0]) # usage raise responseutils.HttpRedirectException(obj.get_absolute_url()) Thomas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
