Hi Waldemar,
On Wed, Oct 27, 2010 at 9:05 PM, Waldemar Kornewald
<wkornew...@gmail.com> wrote:
> 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.
(4) is no good because you might have file name conflicts when used
with multiple reusable applications.
Why haven't you mentioned this problem?
> (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?
I think, in a compressor, you shouldn't rely on STATICFILES_URL but on your own
DJANGO_MEDIAGENERATOR_FILES_URL and DJANGO_MEDIAGENERATOR_FILES_ROOT,
which can be set up to implement necessary strategy from (1)-(4).
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
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.
