Owen,
The file is only created once, so the compression only happens once.
Only when any of the files being aggregated is changed does the file
get recreated.
In other words, the process is automatic, but it has no performance
penalty.
Silvio
On Apr 30, 10:27 am, Owen Nelson wrote:
> In this c
In this case you're compressing at runtime... or am I missing something?
I think I'm just going to burrow for a little while and prototype some
helpers. I've got a project coming up shortly with some room for R&D on
this front, so hopefully I'll be able to put them into production for a
while bef
Consider taking a look at an app I wrote,
http://www.sgawebsites.com/projects/django-aggregator/.
It aggregates all JS and CSS files using a very simple syntax. It can
also pipe the content through YUI Compressor before saving the
aggregate.
My aim was to make it extremely easy to use. It's not a
Kevin Howerton wrote:
> The widget and admin media system needs to be re-evaluated IMO
> none of these solutions are going to address the flaws you are
> referring to.
>
"Flaws", sounds a bit harsh :P Let's alias that as "room for improvement".
I'd agree that wrangling hashes and compressin
>Nothing I've seen so far solves, or even addresses the original need for
>_not_ sourcing the same script numerous times (thanks to widgets with
>their own media)
The widget and admin media system needs to be re-evaluated IMO
none of these solutions are going to address the flaws you are
refer
The django-compress looks a bit better as it has the option to do the
versioning (based on a file hash), compression, and concatenization
with a management command.
Django_compressor does this all on page load, which is not production
worthy IMO.
Generating an MD5 hash on page load is un-needed ov
Yeah, I'm still working through my growing list of projects:
https://www.google.com/bookmarks/l#!threadID=G6K-d-kjbHKA%2FBDSEyZAoQ09_aj4Il
I'm trying to examine each one in terms of features, as well as checking
the source to see how they are working.
Nothing I've seen so far solves, or even addre
Am 22.04.2010 um 20:28 schrieb Ned Batchelder:
FWIW, I just started using django-compress (http://code.google.com/p/django-compress/
) which works precisely this way. It has pluggable compressors,
control over the versioning of the combined files, and so on.
Also worth noting is django_com
FWIW, I just started using django-compress
(http://code.google.com/p/django-compress/) which works precisely this
way. It has pluggable compressors, control over the versioning of the
combined files, and so on.
--Ned.
Gabriel Hurley wrote:
I like the idea of having these "bundles" or "stack
Gabriel,
For addons.mozilla.org we use this syntax:
http://github.com/jbalogh/zamboni/blob/master/settings.py#L268
In TEMPLATE_DEBUG=False, we use a minified version of these assets, in
TEMPLATE_DEBUG=True we just use the individual assets unbundled.
We have a management command which compresse
I like the idea of having these "bundles" or "stacks" for media. Just
thinking out loud here, if there were a compression engine in play
that could do concatenation as well as minification you could have a
useful syntax for ordered combinations of scripts similar to how
ModelAdmin's fieldsets work
I've read hpws, but not the sequel. I suppose following that train of
thought, there should be the option for using 2 separate stacks - one
for the head of the document, and one for the tail (stylesheets at the
top and scripts at the bottom!)
> "These aren't something we could easily incorporate.
"I understand that Django has historically been
anti-javascript-framework-blessing, and I'm wondering if opening this
can of worms would mean having to incorporate some kind of a pluggable
backend system (for working with different frameworks, or multiple
frameworks at a time) - something I've brie
On Wed, Apr 21, 2010 at 11:40 AM, Owen Nelson wrote:
> Jacob Kaplan-Moss wrote:
>> If you'd like to look into it, a good place to start would be by
>> looking at the existing static asset management tools in the ecosystem...
>>
> I most certainly would like to. I'll prepare a "report" with my fin
Jacob Kaplan-Moss wrote:
> If you'd like to look into it, a good place to start would be by
> looking at the existing static asset management tools in the ecosystem...
>
I most certainly would like to. I'll prepare a "report" with my findings.
--
You received this message because you are subs
Hi Owen --
I'd agree that static asset handling in Django needs to be improved,
though like you I'm not sure of the correct direction for this to go
in.
If you'd like to look into it, a good place to start would be by
looking at the existing static asset management tools in the ecosystem
-- last
I've been thinking about this ever since I learned that django's admin
was going to be using jQuery, but I admit I didn't really consider it
that important until recently (building sites against 1.2-beta).
I know now is not a fantastic time to be talking about features, but
this is something I'd e
17 matches
Mail list logo
