Gabriel, For addons.mozilla.org we use this syntax:
http://github.com/jbalogh/zamboni/blob/master/settings.py#L268 In TEMPLATE_DEBUG=False, we use a minified version of these assets, in TEMPLATE_DEBUG=True we just use the individual assets unbundled. We have a management command which compresses/minifies the assets. We also write a number to a build.py file that we can import so our urls for assets have build numbers associated with them. This is done with: http://github.com/jsocol/jingo-minify This is perhaps similar to other tools out there, the only reason we made our own is because we use Jinja2 (via Jingo), but the functions in our helpers.py can easily be ported to Django's native templates. Let me know if that's helpful, and I'm happy to merge in support for Django templates as well. Cheers, d On Apr 21, 12:57 pm, Gabriel Hurley <gab...@gmail.com> wrote: > I like the idea of having these "bundles" or "stacks" for media. Just > thinking out loud here, if there were a compression engine in play > that could do concatenation as well as minification you could have a > useful syntax for ordered combinations of scripts similar to how > ModelAdmin's fieldsets work (using a dictionary of nested tuples). > > A quick example: > > scripts = { > "head": ( > "media/js/script_to_be_loaded_first.js", > ), > "tail": ( > "media/js/script_that_shouldn't_be_concatenated.js", ("media/ > js/concatenate_me_1.js", "media/js/concatenate_me_2.js"), > ) > > } > > That would give you the benefit of automated concatenation while > somewhat alleviating the problem Kevin Howerton pointed out about it > best being done by hand. > > That's my thought for the moment. > > - Gabriel > > On Apr 21, 9:18 am, Owen Nelson <onel...@gmail.com> wrote: > > > > > I've been thinking about this ever since I learned that django's admin > > was going to be using jQuery, but I admit I didn't really consider it > > that important until recently (building sites against 1.2-beta). > > > I know now is not a fantastic time to be talking about features, but > > this is something I'd enjoy working on (personally), and I am just > > hoping to get a little feedback regarding the design, and how it might > > fit in with everything else going on in django's guts > > (philosophically). I also understand that this isn't something for near > > versions of django, but rather the distant future. > > > Here's where the pin dropped: > > * The jQuery used by the admin site is conjured using the no conflict > > option and is relegated/isolated to it's own namespace (excellent). > > * There are many projects/apps out there that also rely on jQuery - they > > also "bundle" the framework, but may not be quite so quick to play nice. > > > In my case, I noticed that when I added a few jQuery-enhanced form > > widgets to a form in my admin site, it resulted in 3 instances of the > > framework being sourced in the document head. Although, this is > > actually ok for the most part in terms of operation (so long as the > > scripted events that come with each widget are bound to the dom before > > the plugin of origin gets wiped by the next sourcing of jQuery), it's > > far from ideal. > > > There are a myriad of ways to skin this cat, be it a simple > > recommendation to adopt the use of django's jQuery and a template tag > > to provide access to the appropriate script tag, or something more > > structured/engineered/formal .... > > > My goal would be to provide app developers with scaffolding to add > > javascript/css resources to the rendered view in a non-competitive way. > > I'm thinking in terms of a template tag that works along the lines of {% > > include %}, but for script and link tags, allowing folks to add scripts > > with an optional way to influence the position in the "stack". A > > similar interface would also be provided for form media, and perhaps > > some kind of helper or shortcut for ease the addition of these scripts > > from our view functions. > > > I understand that Django has historically been > > anti-javascript-framework-blessing, and I'm wondering if opening this > > can of worms would mean having to incorporate some kind of a pluggable > > backend system (for working with different frameworks, or multiple > > frameworks at a time) - something I've briefly considered, but started > > foaming at the mouth as a result. > > I've also considered the fact that the reaction here might be, "just > > don't - leave it all in the individual's hands". > > > In closing... don't hit me! > > > Regards, > > Owen Nelson > > > -- > > 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 > > athttp://groups.google.com/group/django-developers?hl=en. > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
