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.