A simpler template tag about webassets

[miracle2k]

Originally, I specifically opted for the explicit syntax that exists now, because you'd invariably end up needing a way to customize what is automatically inserted. In Django, that would often be done via a template that could be overridden. But since in most cases, you only include the assets tags once in your base template anyway, I'd figured it be much preferable to define the specific html to use right where it will be used, rather than using a separate template (explicitness, Python Zen and so on). I still like that decision today.

On the other hand, I do remember occasionally wishing that there'd be a less verbose way, especially because I can never remember the specific syntax of the link-tag.

So, I'm not completely opposed to something like this, but I do wonder how to do it right. Some thoughts:

• Providing alternative template tags means a lot of maintenance baggage. They'd ideally need to be implemented for both Django and Jinja (and potentially other template languages in the future), and need to be kept up-to-date with new features that are added to the standard tag. I say ideally, because of course both template tags really are essentially extensions for integrating with third party libraries, and not part of the generic "core". Still, it'd be nice if the interfaces were similar.
• How would customization work? Again keeping in mind that different approaches might be needed for Jinja/Django. Would there be a template? Does the tag just accept the desired attributes as arguments?
• There's maybe some overlap with #12 here. For example, if a JSBundle() class where to exist, then instead of "assets_js" style tags, the base tag could be modified to support a simple mode. If I remember correctly how both Jinja and Django's template systems work, then it might even be possible to do this without any syntax changes, i.e. by simply using {% assets %} without defining {% endassets %} - which might be very neat.

I'm sorry to respond to every simple query with a long list of open-ended thoughts, but every wrong design decision now means incompatibilities later. Although SQLALchemy seems to be successful enough with that approach ;)

[statico]

Looking back on this, I think you're right — a tag as simple as assets_js would be too restrictive unless it came with the stipulation, "Only use this tag if you've declared all of your assets in Python."

[kmike]

Hi folks,

A big part of this ticket (plus a part of #12) can be accomplished without going fancy:

# assets.py

# provide some defaults for bundles and create 'js:' and 'css:' namespaces:
def register_css(name, files):
    options = {'filters': 'yui_css,cssrewrite', 'output': '_gen/%s.css' % name}
    register('css:'+name, Bundle(*files, **options))

def register_js(name, files, **options):
    _options = {'filters': 'yui_js', 'output': '_gen/%s.js' % name}
    _options.update(options)
    register('js:'+name, Bundle(*files, **_options))

# usage:
register_js('common', ['js/file1.js', 'js/file2.js'], filters=None)

Then, there are 'inc/js.html' and 'inc/css.html' templates (template for css is almost the same):

{% load assets %}
{% assets bundle %}
    <script type="text/javascript" src="{{ ASSET_URL }}"></script>
{% endassets %}

And then, in order to include the bundle in the template, the following tag (django 1.3) is used:

{% include 'inc/js.html' with bundle="js:common" %}

This doesn't cover all the features from #12 and #26, but that's quite versatile, reduces boilerplate and doesn't introduce extra abstractions/template tags. That's not the prettiest syntax though.

[statico]

@kmike — Good observation. We also have generator functions, and I've pasted them here: https://gist.github.com/1248771

[statico]

I wrote this tag for us today: https://gist.github.com/1249400

In short, we have css(name, files...) and js(name, files...) helpers which declare named asset bundles with a _css or _js suffix. In our templates, all we need to do is use {% assets_css "foo" %} or {% assets_js "bar" %}.

This pretty much emulates Django-Compress, which is the system we moved away from.

I'm not a fan of re-rendering a template, and the extra {% load assets %} markup seems like I'm wasting cycles re-evaluating a template. I'm sure there's a smarter way to do it by either creating Template nodes or reusing the original assets tag functions (but not rewriting the original tag).

[miracle2k]

I would have preferred to make the tag body simply optional, but that does not seem possible in either Jinja or Django. So instead, what about supporting "auto" and type keywords that indicate whether the tag should be auto-generated:

 {% assets js "foo" auto %}
 {% assets js "foo" custom %}....{% endassets %}
 {% assets js "foo" %}....      # could default to either auto or custom
 {% assets "foo" %}....{% endassets %}    # work as always
 {% assets "foo" auto %}....{% endassets %}    # not supported without a type