Hi Yuri,

On Thu, Oct 28, 2010 at 6:19 AM, burc...@gmail.com <burc...@gmail.com> wrote:
> 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?

Which conflict do you mean? If you want to refer to some app's image
from "app/css/style.css" you'd use "app/img/icon.png" with (4) and
"../img/icon.png" with (2). Each path with (4) maps to exactly one
path with (2) and the other way around, so any conflict that applies
to (4) also applies to (2).

>> (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).

Whether URLs are rewritten with STATICFILES_URL or
DJANGO_MEDIAGENERATOR_FILES_URL doesn't make a real difference for
this discussion. I'm fine with either setting, but let's first focus
on the general URL rewriting solution, please.

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.

Reply via email to