-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'layers.finders.AppLayerFinder' #5
Comments
(I'd like to avoid using manage.py collectlayers) |
Hello, You should not need to add {{ site_skin }} to your URL path, assuming you’ve I do not think you can get rid off AppLayerFinder, nor should you want that And I think collectlayers is a desirable feature since it allows you to keep resources Bests, Yoanis. Le 2014-05-05 à 08:16 PM, brycenesbitt notifications@github.com a écrit :
|
I just coded an alternative to AppLayerFinder. It's possible I did not understand AppLayerFinder, but regardless, I now don't need it. The alternative solution is:
Each layer's static files are stored as so: /static/css/foo.css Now as I understood AppLayerFinder 'A request for /static/css/foo.css will result in visitor-a/static/css/foo.css' thus if a browser cached a particular file, it would return the old file. With the {% get_layer_tag %} solution each layer has it's own URL, and thus no cache problems. Does this sound reasonable? With this solution I explicitly decide which static files are layered, and don't get the benefit or cost of fallback to a default. |
django_layers' main use case has been running multiple sites on multiple domains from a (single pool of) process(es). This means there's no caching issue (since the static files will be accessed from different domains, so the browser will treat them as different) If caching is an issue, you'd be better of using the layer as a cache key, e.g.
The magic django_layers attempts to provide is to seemlessly provide the correct "layer" depending on a specific (request) context (e.g. domain name), while trying to be compatible with how existing packages work/treat static resources. E.g. if some packages provides and depends on /static/css/foo.css, django_layers will allow you to override this resource per "layer" I'm not sure if I see a need for explicitly providing additional namespaces per layer like you suggest. It can indeed be handled explicitly this way. Perhaps you could also create some ContextProcessor that overrides STATIC_URL to include the layer name. But that will probably not work for resources that depend on {% static %} |
My use case is a single site on a single IP address on a single domain. Each user can choose a visual 'skin' for the site. It seems a common enough use case and layers is (almost) great for this use case also. |
I was not able to get AppLayerFinder working, for static resources.
I ended up adding a {{ site_skin }} to the context fed to the template:
Would it be possible to have the middleware instead munge STATIC_URL, to add the layer name, and thus avoid the need for the 'layers.finders.AppLayerFinder' middleware?
The text was updated successfully, but these errors were encountered: