Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Made redirect_handler_class/error_handler_class configurable. #467

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants

There are two new fields in Application.settings that are used in
tornado.web for the redirect/error handler classes. These default
to web.RedirectHandler and web.ErrorHandler. These are now handled
in the same was the static_handler_class is. This allows for
subclasses of Application and RequestHandler to customize this
logic more easily.

@ellisonbg ellisonbg Made redirect_handler_class/error_handler_class configurable.
There are two new fields in Application.settings that are used in
tornado.web for the redirect/error handler classes. These default
to web.RedirectHandler and web.ErrorHandler. These are now handled
in the same was the static_handler_class is. This allows for
subclasses of Application and RequestHandler to customize this
logic more easily.
40a8ddd

This PR was originally created to enable some custom PyZMQ request handlers to work without monkey patching. Those classes in PyZMQ have been refactored so this PR is no longer needed for that purpose. Should we close this PR, or do you still want to consider it. If there is still interest in merging this, let me know - I found a few more places that used hardcoded classes in tornado.web.

Owner

bdarnell commented Apr 14, 2013

RedirectHandler is primarily instantiated by user code in the handler list; the one case where Tornado creates its own RedirectHandler is fairly esoteric, and if you want to customize that behavior you're probably going to want to add a wildcard url spec with your own handler instead of plugging in a variant of RedirectHandler.

Overriding ErrorHandler in this way makes more sense since many people have a hard time figuring out that you create a custom 404 page just by adding a wildcard handler at the end of the list. However, I think I'm going to solve that a bit differently by delegating default error handling to the Application (like logging is now), instead of making a new special case for 404s.

@bdarnell bdarnell closed this Apr 14, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment