Hi Carl, On Fri, Oct 29, 2010 at 5:18 AM, Carl Meyer <carl.j.me...@gmail.com> wrote: > Hi Waldemar, > > Thanks for putting so much thought into this issue, and outlining > these options in detail. However, I am not convinced that this > something Django core should be concerned with. I think we need to > maintain a clearer conceptual separation between the various layers of > functionality here.
Just to clarify: We are in fact talking about two questions here: 1. Do we need a standard for URL handling? This is the most important question and my answer is "yes" (I'll explain this in the rest of this mail). 2. I'm suggesting that (4) should be the standard. This is where you focused your reply and from this you somehow concluded that the answer to the first question is "no". The code examples in my previous mail show that we do need a standard (independent of which method becomes the standard). > 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: > > 1. Not all projects want or need to combine/compress their media at > all, and there is no reason they should have to run their CSS through > a URL-rewriting filter. When your CSS files are split into different locations via apps and generated via manage.py collectstatic and served via the staticfiles view it makes no real difference *from a tools perspective*. You already depend on those extra tools/filters, anyway. Your point 3 below is about the human perspective which is the real problem here. > 2. Even in projects that do combine/compress media, there are good > reasons to want to serve the individual files directly in development > (to aid in front-end debugging), and only do the combining/compressing > step on deployment to staging/production. django-mediagenerator and several other asset managers have a view which takes care of serving media uncombined and uncompressed during development for exactly that reason (easier debugging). If you're not yet using a professional asset manager you really try one. It can provide a noticeable speed boost (beyond just combining/compressing media) by utilizing the browser's cache perfectly and it can also help you during development. > 3. Designers and front-end developers working on Django projects > should not have to learn some odd way of linking in their CSS, that > appears to be wrong according to everything they know about how things > usually work. The links they write should make sense to them, not just > to some Python developer who invented a new "standard" for them. I see the point you're trying to make and I don't like that solution (4) breaks with an existing convention, either. There's still the other option of going with (2) for CSS and with (4) for Sass/etc. It's just inconsistent and this becomes even more confusing if you use some language with CSS-like syntax (e.g., SCSS). > 4. Django does not provide any built-in tools to combine, compress, or > rewrite links in media, so it is certainly not going to adopt a > "standard" that requires the use of such a tool. While staticfiles doesn't combine media it definitely is a bulit-in tool and it could easily be extended to rewrite URLs (for the purpose of having a standard). > In other words, the only reason a "standard" would even be needed here > is because you want to establish a new standard which makes the source > CSS files unusable in the absence of a filter which implements the > standard! > > I think the problem here is a desire to conflate multiple issues which > are clearer when considered separately. To wit: > > 1. Links in static files should be written in such a way they work as- > is, without knowing what root URL they will be served under (this > means relative internal links). > 2. Any third-party tool that combines/compresses CSS should be able to > take working input files and generate working output files, handling > whatever internal links it finds correctly. > > Both of these seem almost so obvious that they shouldn't require > stating at all; you'll also note that they keep the question of > internal linkage neatly separated from the presence or absence of a > hypothetical compressor/combiner. I agree with 1. I also fully agree that 2 *should* work the way you described. However, without a standard it can't and in fact this very moment it doesn't. Depending on your asset manager you might use method (1) or (2) or (4) and thus use different URL paths than some other developer. We already have this problem right now: CSS files created for django-compress are incompatible with django-compressor and CSS files created for django-mediagenerator are incompatible with django-compress. Your point 2 doesn't reflect reality. It's a nice dream and an official standard is the first step needed for it to come true. That's what I'm fighting for, here. > The only argument you present against this approach is that it's > problematic for Sass; considering all of my projects use Sass, I > disagree. It simply requires the Sass author to understand the tool > they are using and know how imports and paths work (or use a Sass > framework such as Compass, which already handles the problem neatly). > This is the nature of Sass, is second-nature to any experienced Sass > author, and is in no way specific to Django; there's no reason for > Django to be providing a solution for it. Compass solves this by adding a custom image_url() directive and the paths are pretty much like with method (4), i.e.: they're relative to the root images folder. I'd say this fact supports my suggestion that method (4) is the right one for projects with Sass files. Any other solution would be difficult to understand and bad for reusability because the imported files (e.g., a/_x.sass) would have to know the output file's location (e.g., app/main.css or css/main.css or just main.css or ...). Only (4) is a practical solution for Sass. So, should we * use the same method (4) for CSS and Sass/etc.? (+consistency, -familiarity) * use method (2) for CSS and method (4) for Sass/etc.? (-consistency, +familiarity) 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.
