You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Handling static URLs in aiohttp seems to be a little messy, and I'm wondering if we can do something better. I'd like to discuss potential solutions here.
So, we can use add_static() to create a static resource in aiohttp, but then if we're in aiohttp-jinja2 we can't use that.
Instead, in aiohttp-jinja2 we have a static_root_key on the app, which the user can set (e.g. to /static/) and then aiohttp-jinja2 uses that as a prefix for static resources.
aiohttp-devtools sets this same key on the app in order for aiohttp-jinja2 to work. It sets it to a mutable value which is updated after the app is created to point to the static server (e.g. http://localhost:8001/static/).
One problem here is that we don't get all the usual arguments/features in the static resource (e.g. for cache busting) when we use static files in aiohttp-jinja2. (e.g. aio-libs/aiohttp-jinja2#673) So, it would be nice if we can somehow merge these together, so that aiohttp-jinja2 can work with the static resources better. However, a resource is meant to route locally to the app, but we need something which can be set to a remote location (for aiohttp-devtools, or using a CDN).
Another problem is that if you need to specify the URL for a resource while creating the app (e.g. https://github.com/aio-libs/aiohttp-admin/blob/master/examples/demo/app.py#L62), then it won't work correctly with aiohttp-devtools. This is because it will set static_root_keyafter the app is created. Maybe a solution could involve url_for() returning some kind of dynamic object which recalculates the URL when used?
After writing this all down, I'm wondering if the solution might be to have some kind of new resource object which is not added to the router (or only when explicitly requested?), so it can be used to create URLs. And it can return some kind of object which is tied to the resource, so it will always be up-to-date with the correct prefix. And it should be accessible on a preset key that exists in aiohttp, so all libraries can easily find it.
Handling static URLs in aiohttp seems to be a little messy, and I'm wondering if we can do something better. I'd like to discuss potential solutions here.
So, we can use
add_static()
to create a static resource in aiohttp, but then if we're in aiohttp-jinja2 we can't use that.Instead, in aiohttp-jinja2 we have a
static_root_key
on the app, which the user can set (e.g. to/static/
) and then aiohttp-jinja2 uses that as a prefix for static resources.aiohttp-devtools sets this same key on the app in order for aiohttp-jinja2 to work. It sets it to a mutable value which is updated after the app is created to point to the static server (e.g.
http://localhost:8001/static/
).One problem here is that we don't get all the usual arguments/features in the static resource (e.g. for cache busting) when we use static files in aiohttp-jinja2. (e.g. aio-libs/aiohttp-jinja2#673) So, it would be nice if we can somehow merge these together, so that aiohttp-jinja2 can work with the static resources better. However, a resource is meant to route locally to the app, but we need something which can be set to a remote location (for aiohttp-devtools, or using a CDN).
Another problem is that if you need to specify the URL for a resource while creating the app (e.g. https://github.com/aio-libs/aiohttp-admin/blob/master/examples/demo/app.py#L62), then it won't work correctly with aiohttp-devtools. This is because it will set
static_root_key
after the app is created. Maybe a solution could involve url_for() returning some kind of dynamic object which recalculates the URL when used?After writing this all down, I'm wondering if the solution might be to have some kind of new resource object which is not added to the router (or only when explicitly requested?), so it can be used to create URLs. And it can return some kind of object which is tied to the resource, so it will always be up-to-date with the correct prefix. And it should be accessible on a preset key that exists in aiohttp, so all libraries can easily find it.
Maybe that looks something like:
The text was updated successfully, but these errors were encountered: