I agree, if you want to compress/combine css javascript whatever it's up to the app/tool that does this to fix relative paths and other issues that arrise when compressing/combining files. It has nothing to do with the serving of the files.
On Oct 29, 12:04 pm, "burc...@gmail.com" <burc...@gmail.com> wrote: > Hi Waldemar, > > On Fri, Oct 29, 2010 at 4:19 PM, Waldemar Kornewald > > > > <wkornew...@gmail.com> wrote: > > Hi Yuri, > > > On Fri, Oct 29, 2010 at 10:37 AM, burc...@gmail.com <burc...@gmail.com> > > wrote: > >> Hi Waldemar, > > >> On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald > >> <wkornew...@gmail.com> wrote: > >>> Hi Carl, > > >>>> As I read it, your option 4 means putting URLs into CSS files that > >>>> will not resolve correctly if static files are served directly, > >>>> unmodified, from their source locations (after being collected from > >>>> apps) under STATICFILES_URL (because the URLs you give don't begin > >>>> with a slash, so they will be interpreted as relative to the current > >>>> location; and if they did begin with a slash, that would break anytime > >>>> STATICFILES_URL is not a path-less domain). In other words, you are > >>>> proposing to write CSS files that _depend_ on being run through some > >>>> kind of combiner/compressor/filter that will intelligently rewrite all > >>>> their URLs relative to STATICFILES_URL. As a proposal for a > >>>> "standard," this is a non-starter for several reasons: > >> Do you agree with that "you are proposing to write CSS files that > >> _depend_ on being run through some kind of combiner/compressor/filter > >> that will intelligently rewrite all their URLs relative to > >> STATICFILES_URL"? > > > I keep getting misunderstood, so I'll just simplify it. Forget all my > > proposals. My primary proposal is: > > "Let's have exactly one official standard, no matter if it's (2) or (4)." > > What I don't want is (1), (2), and (4) living side-by-side as they do now. > > > Do you agree that we should have a standard? > > Just a standard? Or standard for some problem related to django? > > > If the answer is "yes", then which one should it be? > > A: (4) for CSS and Sass/etc. > > B: (2) for CSS, (4) for Sass/etc. > > >> If you do, then you understand that you're trying to impose a standard > >> for django users that is really unnecessary for them? > >> You're free to allow such perversion with your app, but please don't > >> try to put this into django. > > >> Why can't you read css files, transform their paths to absolute, merge > >> files, and then write paths back as relative to merged files? > > > That's method (2) which only works well for CSS. > > Django doesn't support Sass. > Django doesn't support media compression. > Why django should have this stupid standard? > > Related to your media compressor, i'd prefer not (2) or (4), i prefer > this one I described above: > 1. Your compressor starts after media is gathered with staticfiles > into a single place. (All relative paths are valid at this moment!) > 2. You read css files, transform their url paths to absolute, merge > files, and then write back into user specified directory with paths > rewritten as relative to merged files location. > 3. If you're copying images, you can put images to whatever folder you > want, but they should still work. > Your compressor should make it possible to work after your compression > if you'll just put that folder to media server. > > That way, every compressor is compatible with each other if their > output is set to compressor-specific folder. > This doesn't impose any standard of writing urls in their files on > django users -- they do what they did before they have any staticfiles > support. > > -- > 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.
