Hi Waldemar, Could you explain why is this should belong to django staticfiles app? This app has nothing to do with combining css files. It has one view (django.contrib.staticfiles.views.serve) in order to serve files in development. This is only a helper view used in development and I don't see why it is necessary to support css-combining solutions in it. If some app combines/compresses css/js files it should handle the path rewriting etc. and provide a way to insert the media into templates (e.g. via templatetag as django-compress do) because all these stuff can be handled in different ways. django.contrib.staticfiles (and it's serve view) doesn't stand in the way here and I think it's the best it could do. If django.contrib.staticfiles prevents something to be implemented then it's an another story and this should be fixed.
On 27 окт, 16:24, Waldemar Kornewald <wkornew...@gmail.com> wrote: > On Thu, Oct 21, 2010 at 10:10 PM, Waldemar Kornewald > > > > > > <wkornew...@gmail.com> wrote: > > 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. > > Since this is pretty important and it would be great to have in the > alpha release, what do you need to be able to make a good decision, > here? > > Bye, > Waldemar -- 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.
