My Django-Compress Tasks
I am thoroughly impressed by django-compress as mentioned in yesterday's post.
There are number of things that I'll be looking to add over the next couple of days that hopefully will make it even more useful for more than just me. I'll be committing these to my fork and submitting pull requests upstream to hopefully have them committing into the main repository.
- For output files, create the intermediary folders if they don't exist.
- Add a gzip option flag to the command to create gzip versions of the output files.
- Add a new css filter for replacing url() property contents with prefixes defined in configuration (allowing for the serving of content locally during development, and then off of CDN servers when deployed).
- Add a new version strategy, that will default to a prefix folder using today's timestamp (YYYYMMDD). Also allow for an optional parameter to the command line to override this default prefix.
- Add another "extra_context" variable called ABSOLUTE_URL to enable an override of both the PREFIX variable I included yesterday as well as the default MEDIA_URL. I need this so as to be able to put things like Google hosted libraries like jQuery, but also to have a quick and easy way to revert to hosting it myself in production.
My goal for these additions is to keep them isolated and non-obstrusive so that they exist if others want to use them but don't get in the way of anything or otherwise clutter up the code.
I'd love to hear any feedback about these or other related ideas.
Commentary
Regarding 'Add a new css filter for replacing url() property contents with prefixes defined in configuration (allowing for the serving of content locally during development, and then off of CDN servers when deployed).':
I solve this by defining a local MEDIA_ROOT and MEDIA_URL in local_settings.py, which I try to import in settings.py.
I have long thought that it needed a timestamp (so you can effectively use it in a semi-production environment) but I don't quite see the rationale in using YYYYMMDD.
Please use a full timestamp. Few extra bytes in the filename but so much more useful (and safe) if you need to push updates to a live server.
Hey, This is really cool, I created someting like this for my own use. Your tool is much more comprehensive though. One thing though that I created in my own. Was the ability to create a group of groups.
That way pages that don't require say a lighbox plugin, don't need to have that js loaded.
Sander: This is precisely what I am trying to avoid. I want the ability to use something other than what I have and am using throughout my site as defined in the MEDIA_* variables.
Oli: The rationale behind YYYYMMDD is that it fits what I am doing and the reason why I plan to provide a command line override. I feel like the daily precision is fine grained enough for a default value, but then again, maybe I could make the default a callable.
I'll think about this some more. Thanks for your input.
Alex: I'd love to hear more about your group of groups approach. Just to be clear, this is not my tool, I merely forked the project and are making some minor additions.
I do agree, however, that this is a great tool and want to do what I can to get people to notice and use it.
I believe your last point is already in compress.
Pelme pulled it from my fork back in november.
Check the docs.
COMPRESS_JS = { 'jquery': { 'external_urls': ( 'http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js', 'http://ajax.googleapis.com/ajax/libs/jqueryui/1.5.2/jquery-ui.min.js' ), }, 'all': { 'source_filenames': ('js/blog.js', 'js/comments.js'), 'output_filename': 'js/all.js', }, }
Andreas: But what about the scenario where you want to host
jquery.min.jsandjquery-ui.min.jsoff your own server when and if you experience problems with googleapis.com for whatever reason?I understand that you might only need daily resolution but does adding hours or minutes really hurt things much?
If it's that worrying, how about something closer to: YYMMDDHH? Same length, 24 times the resolution.
Oli: I am not really that concerned with a few extra characters and am not really saying that I was hard pressed against it.
Paltman: Dunno, im almost never offline developing. Im surrounded with net wherever I go and the chance that google apis goes down is lower than my own connection going down.
That said, I usally run jquery from local when developing anyway, because of most browser ditching the expires header when pressing shift cmd reload.
This is solved easier than you think without adding complexity to compress:
try: from local_settings import * except ImportError, e: pass
Then just put a different COMPRESS_JS dict in local_settings.py with your local copies of jquery, i prefer to use the non minified when im developing.
Those additions sounds like great features, I have been thinking about them myself, but never had the time to finish them up. I am really glad that you are willing to add those features to django-compress, and I will happily merge them.
I think it is good with different choices, but I think that everyone benefit if we can put our efforts together and make one kick-ass app.
What would you gain from specifying versioning in the folders instead of in the filenames?
As suggested, you can use external_urls to add external libraries.
Would that solve your problem?
I have just committed your prefix changes to my github repo and Google Code! I will have a look at the other stuff soon! Thanks a lot!
I've just started learning about django, and came across your site via google. Theres some great info on your website! Thanks for taking the time to chronicle your coding adventures :)