On Thu, Oct 21, 2010 at 10:44 AM, Tobias McNulty <tob...@caktusgroup.com> wrote: > I think the issue is that the commit has already been made, and that doesn't > feel like the right time to anyone to submit an alternate proposal.
Well, that's why we use revision control: if there's a rough consensus that a commit was a mistake, we can revert it. I'm hearing a few voices in this thread that I *think* would like to see the change backed out -- though nobody's actually suggested that explicit yet, so I'm not sure. OTOH, I'm hearing a lot of "whoohoos" from users, so, yes, we couldn't just pull the rug out: we'd need something better to replace it with. > As far as constructive feedback goes, something I would like to see is > making "compilestatic" more configurable: Yes, indeed -- my main concern pre-commit was configurability, and the main focus of my code review was in making sure that we didn't do anything that precluded adding better more powerful features later. I didn't, however, want to hold off adding the feature waiting for some ill-defined set of improvements. I wanted to see a minimalistic addition that we can grow on later. That's how we roll. I think realistically "later" likely means 1.4, but I'd happily review patches adding more hooks at every time. I really don't want staticfiles to be the tool that tries to do everything, though. The idea is to provide the lowest common set of functionality needed to handle media in reusable apps successfully, and then to let other more complicated features (compression, etc.) build on top of that. So yes: more hooks! > One might prefer to serve media > directly from the app static directories (via Aliases in apache or locations > in nginx), instead of copying it manually every time during a deployment. Hm, I certainly wouldn't... but it would be nice to make something like that possible, yes. BTW, you can right now run `collectstatic --links` to use symlinks instead of actually copying the files. Not quite the same thing, but close right now. > Another concern I have is about naming conflicts: how does staticfiles > address the case where multiple apps supply files with the same names? Just like templates: last one wins. See http://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#collectstatic, and also see the `findstatic` command that you can use to debug which file shows up on which name. > This > is something that might also be addressed by being more configurable: I can > see the case where it'd make more sense to expose app-specific URLs for > media to the browser, instead of consolidating everything under a single > global namespace. This could be implemented by a template tag, like so: > {% staticfile 'appname' 'path/to/file.png' %} I'm not quite sure I get the use case here, but like I said above: I would be thrilled to see patches making this more configurable now. Jacob -- 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.
