Hi Yuri, On Fri, Oct 29, 2010 at 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?
A standard for a problem related to Django: How can we have reusable apps that come with media files? How is that possible if everyone uses a different asset manager? Unless I've misunderstood something, the Django team added django.contrib.staticfiles exactly because this app is supposed to solve the reusable-apps-with-media-files problem. We need a standard URL rewriting scheme for this. >> 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? Because practically all asset managers for Django (except for "staticfiles") do support media combining, and a standard is required to make those asset managers compatible with each other, so we can write reusable apps. No standard => no reusable apps. You also can't ignore the growing number of web developers (I've seen a poll saying 20%) who use CSS compilers like Sass. The number is large enough to matter even for Django. > 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. This is method (2). :) It rewrites the URLs relative to the source files before merging (which is your step 2). > 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. You say that you don't want a standard, but what you describe in your mail is a standard. :) What else would you call your three instructions above? They describe how to rewrite URLs according to (2). Please take a look at the existing asset managers: http://djangopackages.com/grids/g/asset-managers/ Only two of them use (2). All the others use (1) and (4). Where do you see the compatibility here? If you still don't agree then see it for yourself: Try to use *exactly* the same reusable app with *exactly* the same CSS files with three different asset managers which combine those app CSS files into a single file. Tell me if it works. You'll see it's impossible. 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.
