Hi Waldemar, On Oct 29, 3:05 am, Waldemar Kornewald <wkornew...@gmail.com> wrote: > 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).
I don't think we need a single end-to-end, all-encompassing standard that tries to cover every possible use case (including Sass, SCSS, etc). Rather than astronaut-architecting an entire hypothetical asset- handling system for all Django users, I think we need to separate the individual potential steps in the asset-handling toolchain and be clear about which of those steps Django is opinionated about, and which it is not. The only conclusion of this that seems reasonable to me does look like your option (2); I'm fine with calling that a standard. I don't believe this standard actually requires documenting (as in your patch), because it's obvious: if your reusable app provides CSS files and images, they should work out of the box as provided, and not rely on any other third-party tool (unless, of course, you document that reliance, which reduces the reusable appeal of your app, but is your choice). > > 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. There is a sharp line in my mind between a tool that collects files into a single tree, and a tool that looks inside the files and munges their contents. The latter dramatically increases the surface area for something to go wrong. While I personally use tools that do both, I think it is appropriate for Django itself to provide a tool that does the former, and strictly avoid the latter. Standardizing on your option (4) would require adding url-munging to staticfiles, or else requiring the use of a third-party tool; I am strongly -1 to either of those. > > 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). And if you write CSS that works as-is, you can now do this without using any tool outside of Django itself (and if you use a combining/ compressing tool, you can simply disable it in development if you want, rather than still needing it to rewrite your internal links for you). > 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. Implicitly denigrating competing tools does not move the discussion forward. > > 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). I don't think that it is at all inconsistent to expect working CSS; anyone using Sass/SCSS simply needs to figure out how to use that tool such that it generates working CSS. > > 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. > > 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. "Takes working input files and generates working output files" is a description of the minimum that I would expect from a well-behaved media compressor. The problem here is that neither django-compress nor django-mediagenerator meet that standard. Django-compress takes working CSS and, depending on your configuration and path layout, may generate broken CSS. Django-mediagenerator requires broken CSS input in order to generate working CSS output. I wouldn't choose to use a tool that doesn't meet the standard of "working input; working output." Others are free to choose as they wish, but I don't support asking reusable apps to standardize on writing broken CSS so they can require the presence of an asset manager to fix it for them. > 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) Framed in your terms, clearly the latter. Let me try to sum up my perspective: It's a basic architectural principle that in order to build a working large and complex system, you break it down into smaller parts, and ensure that each part of the system takes care of its own responsibility, and needs to know as little as possible about the other components of the system in order to do so. This reduces interdependence and increases modular reusability. Here are the parts that have been touched on in this thread, and the responsibility of each one as I see it, arranged such that each piece depends only on knowledge of a single other piece: 1. Reusable apps should put their media in static/appname/ and expect it to be available at STATICFILES_URL/appname/. This is implicitly endorsed by Django due to the inclusion of staticfiles, though of course it is not required. 2. If reusable apps include CSS that links to images or other media, it should work as provided, given only the assumption in (1). (In practice this means relative links, since we don't know the value of STATICFILES_URL in advance). This is also implicitly endorsed by Django, simply because it does not do any link-rewriting: if your provided CSS is broken, Django doesn't fix it for you. 3. A media compressor/combiner should take working input CSS (2) and generate working output CSS. 4. A Sass/SCSS compiler should generate working CSS (2). How it chooses to do so, and what that means for how the Sass/SCSS itself is written, is an internal concern of this part of the system that should not spill over into other parts of the system. I believe in practice this does correspond to what you are calling "option 2 for CSS, option 4 for Sass." When I look at the responsibilities of each part of the system independently, I can't honestly see any other conclusion that makes sense. Parts 3 and 4 are entirely external to Django; if an app wants to do things differently, it's free to do so, and should document its requirements. But if you're asking me about establishing a standard expectation for those areas, this is what I would expect from apps that I would choose to use. Carl -- 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.
