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.
