Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Tree: a863d2d012
Fetching contributors…

Cannot retrieve contributors at this time

179 lines (155 sloc) 9.555 kB
Should bundle names be namespacable, similar to Django urls? At the least,
we probably want to encourage a convention of prefixing your bundle names
with an id. Everything else would just intend to make this easier or more
transparent; for example, bundles could be automatically namespaced based
on which app's file they are defined in, and the template tag
could look at request.current_app when resolving, or take an argument.
There should be some solution though, since it's easy to clash with names
like "js" or "js-all". "admin:js" works much nicer.
--parse-templates currently breaks on asset tags that refer to bundles
by name.
Allow callables that act as filters to be source filters.
Since running an external tool is not uncommon for a filter, the Filter
base class could support a helper function that simplifies the calls to
the subprocess module.
Our updates currently only consider the timestamps, not the assets settings;
that is, adding a new filter or file to a bundle will not cause it to be
recreated automatically.
Automatically create (and delete, i.e. manage) symlinks to make the
ASSETS_EXPIRE="filename" option work without server rewrites.
(a) Support functionality for applying a filter directly within a template,
i.e. pack inline scripts. (b) On the other end, allow piping an assets
directly into the template.
(c) Support a "apply filter but do not merge" mode in which every source
file is written to a corresponding file in a given output directory;
without having to explicitly create a separate bundle for each file. How
would this behave in a nested scenario?
With respect to (b) and (b), it will be challenging to support all those
combinations from within the Django template tag, with it's limited syntax.
Note that the two features do overlap: Both deal with how to output an
Should be provide features for normalizing encodings? This could be
added as properties to the bundles.
Handle far future expires for images: add a new templatetag that can output
image urls with timestamps; the cssrewrite filter could modify urls within
CSS files when ASSETS_EXPIRE is enabled.
Support image sprites like django-media-bundler does.
Find a good solution to making filter debug/log information available in a
standardized way across the board.
Allow an option to fall back to rendering source files in case asset
building fails for some reason. Right now, the user would get to see a
server error. This would probably most simply be accomplished by having
AssetsNode catch exceptions in create_merged() and redirect to
render_sources. We probably want to activate this only in production mode.
Support asset deployment to services like Amazon S3.
In the beginning, there was this idea of "tracking" assets in a model, to
avoid having to parse templates. Now that we conceptually moved towards
defining Bundles in code, that's no longer necessary. Still, there could
still be some uses for it; note enough probably to justify the feature, but
let's note them anyway:
- The model could store things like the bundle hash, allowing a
hash-based update mechanism, even when using say a timestamp cache
buster, or no cache buster at all.
- Right now, if asset properties like the applied filters or the list
of source files change, without causing the source timestamp to
change, the update will not be automatically picked up. That kind of
information could be tracked and used to detect changes better.
Support more expiration/cache busting options (e.g. append hash, use hash
instead of filename, ...); Allow custom code as well.
Add support for Bundle subclasses to customize behavior on a
bundle-by-bundle basis:
- The merging of filtersets.
- Determining when an update is necessary.
- How to expire assets
Basically, all the settings should be customizable this way, with the
settings themselves only serving as a default.
Currently, the docs claim that in a case like this:
Bundle(filter='cssutils', ...), # (1)
Bundle(filter='less,cssutils', ...), # (2)
Bundle(filter='cssutils', ...), # (3)
django-assets cannot apply those filters in two steps. Truth is, we're
just not smart enough; ``less`` COULD be applied first, and then cssutils
over the rest.
How do we currently handle something like this?
less = Bundle('css/base.less', 'css/forms.less', filters='less',
register('all-css', less, 'css/jquery.calendar.css',
filters='yui_css', output="gen/all.css",
debug="merge") # <- !!!!
It seems like this should be a single file, but it probably isn't.
Provide a JSBundle, CSSBundle, AutoDetectBundle (for use in templates)
base classes which would provide a default set of filters; the idea is
to make starting with django-assets easier, but I'm not entirely
convinced it makes sense.
The whole compilation process could be sped up significantly if each
individual step (i.e. every time a filter or a set of filters is applied
to a file) would be cached somewhere (say a temp directory). Rather than
recompiling a bundle in total on every change, only those s subtrees
actually affected would need to be processed.
This might also provide us with a simple way to detect changes based on
which filters are applied, or which source files are contained in a
bundle; changing those properties currently may not cause django-assets
to detect a bundle has having changed, since it only looks at file
timestamps. The cache could easily employ filenames entailing this
information. However, note that this might not be good enough; is the
cache always available? Or would one turn it off in production mode?
Some thoughts on how to use django-assets with compass
(, and how to integrate the
two (if that makes sense at all). Generally speaking, compass provides
a command line util that is used a) as a management script (like doing for example setup work, adding plugins to a project
etc), and b) can compile the sass source files into CSS, and even compress
them. it's this latter functionality that provides some of the functionality
django-assets would be used for, but not all. compass alone doesn't provide
for cache busting, nor can it merge the multiple CSS files it processes
into a single output file. It therefore seems like there is room for
*) The sass filter could be used to compile the source files, the
compass command line utility would only be needed by the dev to
get started with a new project, or adding plugins. The compass
compiler is not used. Not sure if there are compass specific
extensions yet that a pure sass can't compile.
*) A compass filter could run the compass command line utility, based
on a given project file; and then expand itself into the individual
source files given, which could then be further processed by other
filters. Support for this "expanding of files" by filters needs to
be implemented first.
*) Simply a way to cause the compass compiler to be invoked whenever
the django-assets compiler runs, so that not two steps are required
to update ones assets.
Some filters, like the less filter, cannot work with an input stream,
but only with the source files directly. To work, they thus need to be
the first ones to be applied. There should be a way for filters to declare
that requirement and django-assets to automatically validate it.
The less filter has one problem: It is *slow*. I'm not sure whether this
is the default of Ruby or Less itself, but starting up the compiler for
each source file gets unacceptable very soon during development. It's
quite possible that other filters that startup processes, like YUI, have
the same general problem, but it's not noticeable as easily due to that
filter only being applied one for each bundle, not for each source file.
Here are some ideas to improve the situation:
- Currently, we support a "less daemon" mode through a fork of less.
The less daemon runs in the background, and we ask it to compile
stuff through a TCP connection. This helps a lot, but we cannot
realistically expect to add support for such a daemon mode to every
slow filter.
- Somewhat hacky, but a special type of bundle could change the extension
of it's files while in debug mode, between .less and .css. Then, the
less compiler could be run in watch mode by the developer, generating
the .css files for each .less file, and the bundle would cause the
.css files to be rendered as long as we are in debug mode. While
in production, the bundle would expose .sass files, and the normal
filter/merging process of django-assets is done. This at least helps
during developing.
- Before we do that, however, it would probably be much smarter to
simply add a daemon mode to django-assets. It would recompile bundles
in the background transparently, as soon as the developer makes his
change. This would therefore work for all types of filters.
- The less files could be pre-processed to rewrite relative urls
to included files. This being the main reason why we need to run
less for each source file, it could maybe rid us of this requirement.
- The per-file caching suggested further above would help a lot; no
longer would it be required to recompile all source files on every
change - only those that actually changed.
A combination of various of these approaches may be used.
Jump to Line
Something went wrong with that request. Please try again.