Improved static file handling #316

Closed
wants to merge 3 commits into
from

Conversation

Projects
None yet
3 participants

With the default Application setup, it is very hard to change the way static files are served and keep use of the static_url function in your templates. If you supply static_url setting to Application the static handers are always prepended to the handlers with no choice of which handler is used or how static files are served.
In my changes I've made it possible for someone to pass in a different RequestHandler to handle serving static files, but also kept backwards compatibility with the way static files are currently served, people using StaticFileHandler in other ways and the use of the static_url function.

I have also added something similar to the django static files feature documented here:
https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#std:setting-STATICFILES_FINDERS
Basically it allows you to serve your static files from a number of different locations, making it easier to create reusable libraries of UIModules as each of them can hold their own js/css without them needing to be copied into the site's asset folder. See the docs in static.py for more info.

Owner

bdarnell commented Aug 14, 2011

For the first problem, you can actually make this work by setting static_path and then adding your own routes to a custom StaticFileHandler. But that is kind of ugly since the system-added routes are still there but inaccessible, so a simple change to allow a custom handler class for static files would be a good idea (and the bulk of RequestHandler.static_url should probably be delegated to the StaticFileHandler).

I'm not sold on the second part - I'm not sure what the best way is to handle reusable bundles of modules/handlers/etc, but a search path doesn't feel right. I think such a library would need to use a different function instead of the global static_url function so it can be sure of finding its own resources.

Contributor

alekstorm commented Aug 15, 2011

This seems like Tornado is assuming too much work on behalf of the user. Wouldn't it be simpler to eliminate the static_path option and leave it up to the user to register a StaticFileHandler (or subclass) handling the static/* path? This is almost exactly what Tornado does behind the scenes, but requiring the user to write the one line of code themselves would mean that the registration of all handlers is explicitly shown in the app startup code - no magic.

Say we keep the static_handler_class option - what if I need to pass keyword arguments to the constructor of the handler class? Do we add another application setting for every complication, or just pass this information with the already-existing add_handlers() method, as outlined above?

Of course, static_url() currently depends on the static_path setting. We could change this function to something like versioned_url(), which takes a full path, but still adds the v=<hash> option to the URL.

Owner

bdarnell commented Aug 15, 2011

The reason static_path is magic is because there's more to it than just setting up the one handler (because of static_url()). static_path is there to make the common case simple (and static_url_prefix and static_handler_class provide for a little bit of customization). Applications that need more extensive customization can always do as you're suggesting and add the handlers directly, but most apps will be fine with what's currently provided.

The ability to change the static handler class, and its make_static_url method are enough to get by with for the moment. We didn't end up using the static-files-esqe part anyway so if we come up with something better I will contribute it.

Sorry for the delay in closing this.

sjhewitt closed this Sep 21, 2011

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