ourselves, since the can't access a module's static_path (it's only available in encoded form as part of the routes). The previous version didn't pass my own tests, so why I committed this I don't know.
tests specifically for the new module support.
manually, because url_for() requires an application on the stack, which is not guaranteed in cases where our extension is bound permanently to an app object (in which case it may be used outside of an request). So rather than pushing a dummy context on the stack and removing it again, simply build the path using the correct static_path property.
'url' and 'directory' behave now identically, that is, if the user sets a custom value, he completely disables our handling of module-specific paths. Previously, this was only the case for 'url', while in the case of setting a custom 'directory' value, it would only affect where we looked for global application-level static files. Number two, the 'url' and 'directory' do now by default not exist at all, rather than being None. This makes it even clearer that these values are not needed or used unless the user specifically opts to customize them.
is used, only when indexing into the config object.
confusion about the use of app.static_path is cleared up.
directory the static files are served *from* is currently hardcoded in Flask to be 'static'.
Flask app under a path.
default url and directory settings via the config, since the values set by the user were always overwritten by the Flask-Assets defaults. This bug is now gone, but add a regression test for it.
previous commit supported. Now, if you do not bind the extensions to an application, you can basically only use the extension object within a request context. This is less functionality, but keeps things simpler.