2010/10/27 Mikhail Korobov <kmik...@googlemail.com>:
> Why isn't it fine to have different URL rewriting schemes for
> different assets bundlers?
OK, sorry for not having explained it well. What I mean is this:
Imagine this code snippet in a reusable app's CSS file:
/* myapp/style.css */
div.icon {
background-image: url(img/icon.png);
}
Now this file gets combined into "css/main.css". Depending on which
asset manager and URL rewriting scheme you use the URL can be:
1. unmodified: "img/icon.png"
2. relative to the current file: "/static/myapp/img/icon.png"
3. relative to the combined file: "/static/css/img/icon.png"
4. relative to STATICFILES_URL "/static/img/icon.png"
If one developer who uses an asset manager based on (2) publishes a
reusable app and another developer who uses an asset manager based on
(4) publishes a reusable app there is no way to put both apps into
your project and have both work correctly with the same asset manager.
Note, in practice, (1) and (3) have pretty much the same result.
Anyway, (1) and (3) would be very bad ideas if you want to support
combined files, so let's leave them out of this discussion.
(2) is what everyone is used to, but it's inconsistent if you use Sass
or other CSS compilers because they allow importing other files which
might also contain URLs and there's no way for the asset manager to
rewrite URLs relative to the imported file's path (the asset manager
only gets one big result file which already contains all imported
files). This inconsistency is annoying e.g. when you develop both with
CSS and Sass.
(4) is fully consistent and easy to understand, but obviously behaves
differently from what most people are used to when developing .
However, this way all URLs look the same, no matter if you use Sass or
CSS or both.
(1), (2), and (3) would already be compatible with the current
staticfiles implementation. (4) would require a little modification.
I've seen (1), (2), and (4) used in practice when combining CSS files.
Which behavior should be the standard for all asset managers?
Bye,
Waldemar
--
Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
http://www.allbuttonspressed.com/blog/django
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
