Hi Waldemar, it seems I just don't get what does "relative to" mean in your (1)-(4). Could you please explain better, what do you mean by that? Starting with what path does your "css/main.css" have? I think you've missed some important bits in your explanations, or just not covering every possible choice. I presumed that with making css/main.css you're just copying that image over to your new location like staticfiles does (or symlinking images folder).
On Thu, Oct 28, 2010 at 1:29 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > 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" > > 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. > > -- 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.