Support for modern webdev practices/technologies

[jannon]

Okay here is a pull request that repackages and cleans up a couple earlier requests

What's in this pull request

• Let tag arguments after kind (css|js) be specified in any order
• Use more standard 'as ' syntax to name the code block
• Add ability to specify options in the tag
• Ability to group files before processing
• Ability to redirect tag output to template context variable

There are tests and documentation updates as well as the code changes

Tag Argument Order

There's not really any need to enforce a certain arrangement of arguments in the tag so let's just let people specify them however they want after the kind parameter. So now all of these are valid:

{% compress js inline as main %}

{% compress js as main file %}

{% compress css group_first=true as base %}

Using 'as <name>'

Lots of things in python and django use this syntax, so it would be nice to do so as well

Specifying options in the tag

Just like the with tag in django, you can specify an arbitrary number of keyword/value arguments to the tag. These will get put into a dictionary and passed to the Compressor classes. Also, the default compressors add these to the options that they pass the precompilers and filters. One of the main motivations for this was to prepare for being able to specify that files should be grouped first before, say, lessc precompilation (as discussed in #30) Currently supported options:

• group_first - if 'group_first=true' is specified, files of like type will be concatenated before being handed to precompilers/filters
• deferred - if 'deferred=true' is specified AND 'as ' is specified the results of the template tag are stored in a template context variable

Concatenating files before processing (fixes #30)

As mentioned above, using the group_first=true tag options will concatenate files before processing. This is useful for having django_compressor work for best practices like separate mixins.less and page.less files

Template context variable (fixes #249)

As mentioned above, using 'deferred=true' and 'as " in the template tag will cause the output to be placed in a template context variable rather than rendered immediately. This is useful for capturing the results of the compression (the url) for use with asynchronous resource loaders (e.g. yepnope.js, require.js, etc.). In fact, if the output mode is 'file', the 'deferred' option set the template variable to be just the compressed url (without 'script' tag). If the mode is 'inline' the template variable just contains whatever the output would have been normally

[travisbot]

This pull request fails (merged cd64b11 into 41d5e52).

[Deraen]

This does not work when using offline compression:

    {% compress js deferred=true as js_history %}
    <script type="text/javascript" src="{{ STATIC_URL }}js/jquery.history.js"></script>
    {% endcompress %}

    {% compress js %}
    <script type="text/javascript" src="{{ STATIC_URL }}js/yepnope.1.5.4-min.js"></script>
    <script type="text/javascript">
    ...
    yepnope('{{ js_history }}');
    ...
    </script>
    {% endcompress %}

OfflineGenerationError: You have offline compression enabled but key "9a67e822d7f98c94f109bb4075fb8ad5" is missing from offline manifest. You may need to run "python manage.py compress".

This is because when running compress command, the second block will be rendered without js_history variable and will get different hexdigest than when rendering template.
This can be fixed by removing context.push()/pop() from management/commands/compress.py lines 269 and 283, then context wont be reseted between different compress blocks and second block can access variable from first block.

[diox]

FYI : I like this pull request a lot, haven't checked all the code yet but I'd love to integrate it. We're about to push a new release, I'll take a closer look once that is done.

@Deraen problem needs to be fixed however, and a testcase added. I'm not sure simply removing the context push/pop is the right path, we might need something a little more clever, as we don't want to pollute the context for all compress blocks.

[diox]

Release was done a few weeks ago, so let's try to work on merging this.

@jannon : can you look at the travis test failures and see if @Deraen's problem can be fixed easily ? I'm available on IRC to discuss this if needed.

[kingtut]

This would be better as re.findall to output a list of all files for debug (or compress=False) mode.

[diox]

@jannon : most of this PR probably still applies, but I can't merge this without fixes for the test failures (and conflicts, since this is old).

[k-funk]

Would really like to see this go out if you still have time @jannon . If not, let us know and hopefully someone else can work on it.

[iamareebjamal]

If a PR with conflicts resolved and passing tests is made, will it be merged?

Wanting to ensure my time and efforts won't go to waste

[karyon]

generally, sure, if the code looks good and the benefit justifies the added complexity. Although I'd prefer to have at least separate commits if not separate PRs for the individual features, so they can be easier reviewed, worked on, and merged separately. otherwise it could stall again as this PR did :)

Is there anything in particular you're interested in? I'm wondering e.g. whether loaders (which seem to be the motivation for "Template context variable") are still a thing... (I honestly don't know)

[iamareebjamal]

I'm mainly interested in merging resources before passing them to the processor.

So, yeah, I'll create a focused PR on that and move forward with one PR for one feature (unless the requirements of features overlap the code changes)

Loaders are still a thing, and that is second priority for me, but that functionality is totally separate(and more complex AFAIK) and hence, warrants a separate PR