Comments (6)
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 ;)
from webassets.
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."
from webassets.
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.
from webassets.
@kmike — Good observation. We also have generator functions, and I've pasted them here: https://gist.github.com/1248771
from webassets.
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).
from webassets.
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
from webassets.
Related Issues (20)
- jsmin/rjsmin removes blanks in ES6 Template Strings HOT 1
- Fail when packing an external resource HOT 4
- YAMLLoadWarning yaml.load is deprecated
- Bundles cannot be replaced/re-added
- --line-comments is deprecated
- LibSASS - Unable to use other compile options like source_comments
- Version 2: Couldn't find preset HOT 3
- Threading.isAlive was removed in Python 3.9
- Load_builtin_filters doesn't work as expected with PyInstaller
- Deprecation warning due to invalid escape sequences in Python 3.7
- Fix simple typo: ultimatily -> ultimately
- Closure: ReferenceError: $jscomp is not defined
- Copy assets
- SCSS filter runs command sass without --scss HOT 2
- Add a tool to remove unused css
- How to configure filters using the YAML config option? Specifically cssrewrite. HOT 1
- Jinja2 Base template loaded twice when upgrading werkzeug package
- Add a way to get all bundle names
- 'out' is deprecated and will stop functioning in TypeScript 5.5
- mode merge=False not implemented in flask_assets
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webassets.