'layers.finders.AppLayerFinder'

[brycenesbitt]

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?

[brycenesbitt]

(I'd like to avoid using manage.py collectlayers)

[yoanisgil]

Hello,

You should not need to add {{ site_skin }} to your URL path, assuming you’ve properly setup your HTTP server to serve the static content for each configurable skin/layer.

I do not think you can get rid off AppLayerFinder, nor should you want that as it’s essential to the functioning of the project (take cares of loading the right template, for instance).

And I think collectlayers is a desirable feature since it allows you to keep resources from the different resources separated and in sync.

Bests,

Yoanis.

Le 2014-05-05 à 08:16 PM, brycenesbitt notifications@github.com a écrit :

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?

— Reply to this email directly or view it on GitHub.

[brycenesbitt]

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:

---

# Custom tag for django-layers
@register.simple_tag(takes_context=True)
def get_layer_tag(context):
    request = context['request']
    return layers.get_layer(request)

Then in each template:
<link href="{{ STATIC_URL }}{% get_layer_tag %}/css/foo.css" rel="stylesheet">

---

Each layer's static files are stored as so:

/static/css/foo.css /static/visitor-a/css/foo.css /static/visitor-b/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.

[iivvoo]

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.

{{ STATIC_URL }}/css/foo.css?{% get_layer_tag %}

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 %}

[brycenesbitt]

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.