On Thu, Oct 21, 2010 at 7:20 PM, flo...@gmail.com <flo...@gmail.com> wrote:
> I think staticfiles is an *excellent* contribution, and if there is
> some advanced use case that it doesn't do, then let's do our best to
> make it extensible enough to make that use case possible.  Easy things
> (like bundling media with your app) should be easy, but hard things
> (like minification and consolidation of js) should be possible.

OK, I just went through django-mediagenerator to check if there's
anything else needed by staticfiles and I noticed that we need to have
a standard for URLs in CSS files (e.g., url(image.png)).

Since we don't know the STATICFILES_URL in our CSS code we have to use
relative paths when referencing images. When CSS files get combined
the resulting file is often in a different folder than its source
files. This will break relative paths. Now we have these solutions:
1. keep URLs untouched when combining
2. rewrite URLs relative to source files
3. rewrite URLs relative to the combined file's path
4. rewrite URLs relative to STATICFILES_URL

URL rewriting would convert relative paths to absolute URLs beginning
with STATICFILES_URL.

(1) is the easiest solution and it might be used by very simple asset
managers. This approach is also used by quite a few CSS and JS
frameworks (e.g. jQuery UI). Disadvantage: It only works if the
combined CSS file is in the same location as its source files.

(2) is very intuitive because it behaves exactly like with uncombined
files. Disadvantage: URL rewriting is inconsistent if you also support
CSS compilers like Sass because the URLs used in imported files would
be relative to the master file. This means imported files have to make
assumptions about the master file's location which is very confusing
and bad for reusability.

(3) is too confusing and makes too many assumptions about the combined
file's location which is confusing and bad for reusability.

(4) is the most consistent solution. No matter whether you use a CSS
compiler or normal CSS files or something else, URLs always behave the
same. Disadvantage: At first you might expect different behavior, so
it's quite not as intuitive as (2), but it's very easy to understand
once you know what it does. Also, it doesn't have any of the
disadvantages of (2).

IMHO, (4) is the best solution because it's consistent. (2) is the
second best solution. It should be easy to adapt the code in
django-mediagenerator and make a little patch for staticfiles, so it
behaves like (4). What do you think?

In any case, staticfiles would need to rewrite URLs in its view, too.
Otherwise we can't provide a consistent solution across all asset
managers.

Bye,
Waldemar Kornewald

-- 
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