Re: managing javascript and css resources

[Silvio]

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 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 on
> this front, so hopefully I'll be able to put them into production for a
> while before I bug anyone again.
> I'll be back (at some point) when I've got something I think will
> benefit the community.
>
> Thanks for all the interest in the topic though - I think that proves we
> are all hungering for *something* even if we're not exactly sure as to
> what it is.
>
> Silvio wrote:
> > 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 an asset manager
> > though; I've yet to see or come up with a great solution.
>
> > Regards,
>
> > Silvio
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Owen Nelson]

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 on
this front, so hopefully I'll be able to put them into production for a
while before I bug anyone again.
I'll be back (at some point) when I've got something I think will
benefit the community.

Thanks for all the interest in the topic though - I think that proves we
are all hungering for *something* even if we're not exactly sure as to
what it is.

Silvio wrote:
> 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 an asset manager
> though; I've yet to see or come up with a great solution.
>
> Regards,
>
> Silvio
>   

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Silvio]

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 an asset manager
though; I've yet to see or come up with a great solution.

Regards,

Silvio

On Apr 23, 10:51 am, Owen Nelson  wrote:
> 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 compressing assets at run-time is
> undesirable, and that a management command is preferable.
> There's a bit of conflict between what I crave, and the
> compress-everything-ahead-of-time tactic though.  Actually... I take
> that back - following Gabriel's train of though, we could probably have
> it both ways.
>
> Since my goals are somewhat smaller (in some ways), I've started
> thinking about ways to implement what I want (some kind of "global"
> stack of client-side resources) that won't require sticking my fingers
> in the django source.  At least not yet.
> Here's kind of what I'm thinking about:http://dpaste.org/Pjk5/
> (Sorry, the naming is all a bit clunky - that was just off the top of my
> head)
>
> Extending something simple like that with some template tags, and
> stringing it all together with some middleware.
> This would give us a way to pool scripts together under one framework
> instance, also allowing us to dynamically add (from views and templates)
> them to the framework container throughout the life cycle of a request
> and response.
> I think I might be able to run some tests in a custom app - then start
> experimenting with the admin site.
>
> Once I've got all that setup, it should be a snap to add
> compression/concatenation somewhere along the  pipeline, either at
> runtime or via a management command.
>
> Obviously, this is all very jQuery specific (where most of my javascript
> experience lies).  I'd love to hear from someone on team dojo,
> prototype, yui, or extjs to learn about what doesn't fit with this model.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Owen Nelson]

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 compressing assets at run-time is
undesirable, and that a management command is preferable.
There's a bit of conflict between what I crave, and the
compress-everything-ahead-of-time tactic though.  Actually... I take
that back - following Gabriel's train of though, we could probably have
it both ways.

Since my goals are somewhat smaller (in some ways), I've started
thinking about ways to implement what I want (some kind of "global"
stack of client-side resources) that won't require sticking my fingers
in the django source.  At least not yet.
Here's kind of what I'm thinking about:
http://dpaste.org/Pjk5/
(Sorry, the naming is all a bit clunky - that was just off the top of my
head)

Extending something simple like that with some template tags, and
stringing it all together with some middleware.
This would give us a way to pool scripts together under one framework
instance, also allowing us to dynamically add (from views and templates)
them to the framework container throughout the life cycle of a request
and response.
I think I might be able to run some tests in a custom app - then start
experimenting with the admin site.

Once I've got all that setup, it should be a snap to add
compression/concatenation somewhere along the  pipeline, either at
runtime or via a management command.

Obviously, this is all very jQuery specific (where most of my javascript
experience lies).  I'd love to hear from someone on team dojo,
prototype, yui, or extjs to learn about what doesn't fit with this model.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Kevin Howerton]

>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
referring to.

What we need is an API for form actions, and a standard set of drivers
(reference implementation included in "your favorite js framework").

Once you have that, you can have your widgets know what js-driver-set
you are using and avoid duplicate importation of the core framework
components.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Kevin Howerton]

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 overhead as well.  In
order to do this you are loading each js/css file into memory as you
render your templates. If you are using either of these tools in
production I highly recommend that you have those template fragments
cached.

Our compression scripts rely on the git-hash.  The negative to this is
that when you increase your version you expire every css/js file,
though I feel this might be a benefit in some ways (we can alter all
of our JS based by changing a version number in our settings file).
The real positive to this is that you don't even touch the filesystem
in production, let alone have to generate an md5 hash.

As far as concatenization goes, I really believe that this at least
should be separated out from the templates, if not just simply done by
hand.  Having random different concatenization of css/js littered
throughout 100+ templates can be a bit daunting to maintain.  Doing
the concat in a python file would work very well though

global = ('carousel.js', 'menu-bar.js', 'modal.js')
newspage = ('widgets.js', 'calendar.js', 'weather.js')

I've always just achieved the same effect by just throwing all the
different little files that are required for each page type ... into
one file, though that's probably due to a lack of an acceptable
alternative solution rather than anything else.

-k

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Ulrich Petri]

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_compressor *) (http://github.com/mintchaos/django_compressor 
) which works similar but uses template tags to define bundles (which  
IMHO is way more natural than defining them in settings)


*) not to be confused with django-compressor (_ vs -)

Bye,
Ulrich



--Ned.

Gabriel Hurley wrote:


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 (using a dictionary of nested tuples).

A quick example:

scripts = {
"head": (
"media/js/script_to_be_loaded_first.js",
),
"tail": (
"media/js/script_that_shouldn't_be_concatenated.js", ("media/
js/concatenate_me_1.js", "media/js/concatenate_me_2.js"),
)
}

That would give you the benefit of automated concatenation while
somewhat alleviating the problem Kevin Howerton pointed out about it
best being done by hand.

That's my thought for the moment.

- Gabriel

On Apr 21, 9:18 am, Owen Nelson  wrote:

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 enjoy working on (personally), and I am just
hoping to get a little feedback regarding the design, and how it  
might

fit in with everything else going on in django's guts
(philosophically).  I also understand that this isn't something  
for near

versions of django, but rather the distant future.

Here's where the pin dropped:
* The jQuery used by the admin site is conjured using the no  
conflict

option and is relegated/isolated to it's own namespace (excellent).
* There are many projects/apps out there that also rely on jQuery  
- they
also "bundle" the framework, but may not be quite so quick to play  
nice.


In my case, I noticed that when I added a few jQuery-enhanced form
widgets to a form in my admin site, it resulted in 3 instances of  
the

framework being sourced in the document head.  Although, this is
actually ok for the most part in terms of operation (so long as the
scripted events that come with each widget are bound to the dom  
before
the plugin of origin gets wiped by the next sourcing of jQuery),  
it's

far from ideal.

There are a myriad of ways to skin this cat, be it a simple
recommendation to adopt  the use of  django's jQuery and a  
template tag

to provide access to the appropriate script tag, or something more
structured/engineered/formal 

My goal would be to provide app developers with scaffolding to add
javascript/css resources to the rendered view in a non-competitive  
way.
I'm thinking in terms of a template tag that works along the lines  
of {%
include %}, but for script and link tags, allowing folks to add  
scripts

with an optional way to influence the position in the "stack".  A
similar interface would also be provided for form media, and perhaps
some kind of helper or shortcut for ease the addition of these  
scripts

from our view functions.

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 briefly considered, but  
started

foaming at the mouth as a result.
I've also considered the fact that the reaction here might be, "just
don't - leave it all in the individual's hands".

In closing... don't hit me!

Regards,
Owen Nelson

--
You received this message because you are subscribed to the Google  
Groups "Django developers" group.
To post to this group, send email to django-developers@googlegroups.com 
.
To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com 
.
For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en 
.








--
You received this message because you are subscribed to the Google  
Groups "Django developers" group.
To post to this group, send email to django-developers@googlegroups.com 
.
To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com 
.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en 
.


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, 

Re: managing javascript and css resources

[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.


--Ned.

Gabriel Hurley wrote:

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 (using a dictionary of nested tuples).

A quick example:

scripts = {
"head": (
"media/js/script_to_be_loaded_first.js",
),
"tail": (
"media/js/script_that_shouldn't_be_concatenated.js", ("media/
js/concatenate_me_1.js", "media/js/concatenate_me_2.js"),
)
}

That would give you the benefit of automated concatenation while
somewhat alleviating the problem Kevin Howerton pointed out about it
best being done by hand.

That's my thought for the moment.

- Gabriel

On Apr 21, 9:18 am, Owen Nelson  wrote:
  

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 enjoy working on (personally), and I am just
hoping to get a little feedback regarding the design, and how it might
fit in with everything else going on in django's guts
(philosophically).  I also understand that this isn't something for near
versions of django, but rather the distant future.

Here's where the pin dropped:
* The jQuery used by the admin site is conjured using the no conflict
option and is relegated/isolated to it's own namespace (excellent).
* There are many projects/apps out there that also rely on jQuery - they
also "bundle" the framework, but may not be quite so quick to play nice.

In my case, I noticed that when I added a few jQuery-enhanced form
widgets to a form in my admin site, it resulted in 3 instances of the
framework being sourced in the document head.  Although, this is
actually ok for the most part in terms of operation (so long as the
scripted events that come with each widget are bound to the dom before
the plugin of origin gets wiped by the next sourcing of jQuery), it's
far from ideal.

There are a myriad of ways to skin this cat, be it a simple
recommendation to adopt  the use of  django's jQuery and a template tag
to provide access to the appropriate script tag, or something more
structured/engineered/formal 

My goal would be to provide app developers with scaffolding to add
javascript/css resources to the rendered view in a non-competitive way.
I'm thinking in terms of a template tag that works along the lines of {%
include %}, but for script and link tags, allowing folks to add scripts
with an optional way to influence the position in the "stack".  A
similar interface would also be provided for form media, and perhaps
some kind of helper or shortcut for ease the addition of these scripts
from our view functions.

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 briefly considered, but started
foaming at the mouth as a result.
I've also considered the fact that the reaction here might be, "just
don't - leave it all in the individual's hands".

In closing... don't hit me!

Regards,
Owen Nelson

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group 
athttp://groups.google.com/group/django-developers?hl=en.



  


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Dave Dash]

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 compresses/minifies the assets.  We
also write a number to a build.py file that we can import so our urls
for assets have build numbers associated with them.

This is done with:

http://github.com/jsocol/jingo-minify

This is perhaps similar to other tools out there, the only reason we
made our own is because we use Jinja2 (via Jingo), but the functions
in our helpers.py can easily be ported to Django's native templates.

Let me know if that's helpful, and I'm happy to merge in support for
Django templates as well.

Cheers,

d


On Apr 21, 12:57 pm, Gabriel Hurley  wrote:
> 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 (using a dictionary of nested tuples).
>
> A quick example:
>
> scripts = {
>     "head": (
>         "media/js/script_to_be_loaded_first.js",
>     ),
>     "tail": (
>         "media/js/script_that_shouldn't_be_concatenated.js", ("media/
> js/concatenate_me_1.js", "media/js/concatenate_me_2.js"),
>     )
>
> }
>
> That would give you the benefit of automated concatenation while
> somewhat alleviating the problem Kevin Howerton pointed out about it
> best being done by hand.
>
> That's my thought for the moment.
>
>     - Gabriel
>
> On Apr 21, 9:18 am, Owen Nelson  wrote:
>
>
>
> > 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 enjoy working on (personally), and I am just
> > hoping to get a little feedback regarding the design, and how it might
> > fit in with everything else going on in django's guts
> > (philosophically).  I also understand that this isn't something for near
> > versions of django, but rather the distant future.
>
> > Here's where the pin dropped:
> > * The jQuery used by the admin site is conjured using the no conflict
> > option and is relegated/isolated to it's own namespace (excellent).
> > * There are many projects/apps out there that also rely on jQuery - they
> > also "bundle" the framework, but may not be quite so quick to play nice.
>
> > In my case, I noticed that when I added a few jQuery-enhanced form
> > widgets to a form in my admin site, it resulted in 3 instances of the
> > framework being sourced in the document head.  Although, this is
> > actually ok for the most part in terms of operation (so long as the
> > scripted events that come with each widget are bound to the dom before
> > the plugin of origin gets wiped by the next sourcing of jQuery), it's
> > far from ideal.
>
> > There are a myriad of ways to skin this cat, be it a simple
> > recommendation to adopt  the use of  django's jQuery and a template tag
> > to provide access to the appropriate script tag, or something more
> > structured/engineered/formal 
>
> > My goal would be to provide app developers with scaffolding to add
> > javascript/css resources to the rendered view in a non-competitive way.
> > I'm thinking in terms of a template tag that works along the lines of {%
> > include %}, but for script and link tags, allowing folks to add scripts
> > with an optional way to influence the position in the "stack".  A
> > similar interface would also be provided for form media, and perhaps
> > some kind of helper or shortcut for ease the addition of these scripts
> > from our view functions.
>
> > 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 briefly considered, but started
> > foaming at the mouth as a result.
> > I've also considered the fact that the reaction here might be, "just
> > don't - leave it all in the individual's hands".
>
> > In closing... don't hit me!
>
> > Regards,
> > Owen Nelson
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > 

Re: managing javascript and css resources

[Gabriel Hurley]

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 (using a dictionary of nested tuples).

A quick example:

scripts = {
"head": (
"media/js/script_to_be_loaded_first.js",
),
"tail": (
"media/js/script_that_shouldn't_be_concatenated.js", ("media/
js/concatenate_me_1.js", "media/js/concatenate_me_2.js"),
)
}

That would give you the benefit of automated concatenation while
somewhat alleviating the problem Kevin Howerton pointed out about it
best being done by hand.

That's my thought for the moment.

- Gabriel

On Apr 21, 9:18 am, Owen Nelson  wrote:
> 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 enjoy working on (personally), and I am just
> hoping to get a little feedback regarding the design, and how it might
> fit in with everything else going on in django's guts
> (philosophically).  I also understand that this isn't something for near
> versions of django, but rather the distant future.
>
> Here's where the pin dropped:
> * The jQuery used by the admin site is conjured using the no conflict
> option and is relegated/isolated to it's own namespace (excellent).
> * There are many projects/apps out there that also rely on jQuery - they
> also "bundle" the framework, but may not be quite so quick to play nice.
>
> In my case, I noticed that when I added a few jQuery-enhanced form
> widgets to a form in my admin site, it resulted in 3 instances of the
> framework being sourced in the document head.  Although, this is
> actually ok for the most part in terms of operation (so long as the
> scripted events that come with each widget are bound to the dom before
> the plugin of origin gets wiped by the next sourcing of jQuery), it's
> far from ideal.
>
> There are a myriad of ways to skin this cat, be it a simple
> recommendation to adopt  the use of  django's jQuery and a template tag
> to provide access to the appropriate script tag, or something more
> structured/engineered/formal 
>
> My goal would be to provide app developers with scaffolding to add
> javascript/css resources to the rendered view in a non-competitive way.
> I'm thinking in terms of a template tag that works along the lines of {%
> include %}, but for script and link tags, allowing folks to add scripts
> with an optional way to influence the position in the "stack".  A
> similar interface would also be provided for form media, and perhaps
> some kind of helper or shortcut for ease the addition of these scripts
> from our view functions.
>
> 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 briefly considered, but started
> foaming at the mouth as a result.
> I've also considered the fact that the reaction here might be, "just
> don't - leave it all in the individual's hands".
>
> In closing... don't hit me!
>
> Regards,
> Owen Nelson
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Owen Nelson]

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.  Just automating
> JS and CSS bundling and compression would be a big help.  This is a
> good place to start on that:"
Yes, I suppose it is.  Keeping track of an ordered "set" of resources
referenced by a particular view would mean we have a strong place from
which to handle that kind of transformation.  I wasn't actually planning
on bringing that up since at least initially my priority would be to
work on ways to keep our frontend code DRY -- just like our python code :)
> Also I don't like how some of the available libraries encourage
> concatenization of js/css files that shouldn't be concatenated (that
> should all be done by hand for best results IMO).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Kevin Howerton]

"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 briefly considered, but started
foaming at the mouth as a result."

We should look to Rails 3 JS Helpers for some prior art ... I have a pretty
good idea of how we can easily have a widget system that spits out JS of
your desired flavor... I just have to write the code.. heh.

"These aren't something we could easily incorporate.  Just automating
JS and CSS bundling and compression would be a big help.  This is a
good place to start on that:"

I have a build-bot that appropriately compresses and versions our JS and
GZips it... then sends it off to our CDN. I use a template tag to vary on
user-agent to serve up the ungzipped content to IE6.  I've found this to be
the preferred method over available open-sourced django tags... It does
almost zero processing at runtime  (just the tag that varies on user-agent).

Also I don't like how some of the available libraries encourage
concatenization of js/css files that shouldn't be concatenated (that should
all be done by hand for best results IMO).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Jeremy Dunck]

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 findings.

I'm an enthusiast on this topic -- if you haven't yet, have a look at
YSlow and Souder's two books:
http://www.stevesouders.com/hpws/
http://www.stevesouders.com/efws/

FWIW, I think GWT took an early lead with image bundling (automated
creation of sprites).  Lots of frameworks have caught up to that, but
they may have improved their lead since I last looked.

More recently, Cappuccino added some great support for bundling-- in
particular, I was interested in their cross-browser approach for
inlining content.
http://cappuccino.org/discuss/2009/11/11/just-one-file-with-cappuccino-0-8/

These aren't something we could easily incorporate.  Just automating
JS and CSS bundling and compression would be a big help.  This is a
good place to start on that:
http://stackoverflow.com/questions/28932/best-javascript-compressor

I've played off and on with making great asset handling for Django.
We had something to do automated spriting at Pegasus, but I don't have
that code any more (their IP).  For example, avatars for the X most
frequent commenter's avatars:
http://media.pegasusnews.com/pegasus/bundles/img/8a339a7ffaf8e89432732f3d7c67ede6.jpg

In general, I found it difficult to provide great support without some
heavy JS, and picking a JS framework would make it difficult to
include in core.  Also, we used a media server 404 handler for
thumbnailing, which is outside the range of Django; maybe Sorl has a
better answer here.

This presentation has some nice ideas, too:
http://assets.en.oreilly.com/1/event/29/The%20Secret%20Weapons%20of%20the%20AOL%20Optimization%20Team%20Presentation.pdf
(SONAR, particularly-- nothing is faster than skipping load of
something that isn't actually needed.)

One more idea that I haven't seen anyone doing yet is to inline
content that would miss the browser cache, and background load any
assets likely to be needed later.  Roughly speaking, there would be a
cookie whose value is a bloom filter of which assets have been
downloaded to local cache.  On a request, the server would inline all
assets needed for the page, and set up background loading of any
high-priority assets, updating the cookie as loads occurred.  Total
transfer would be higher (due to overlap between inlined and
backgrounded loads), but perceived response time should be hugely
improved.

Thanks for your interest in this topic!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Owen Nelson]

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 subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: managing javascript and css resources

[Jacob Kaplan-Moss]

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 checked there were at least a half-dozen -- and evaluating
them and their differences. If there's a clear winner, we might start
looking at bundling it with Django.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

managing javascript and css resources

[Owen Nelson]

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 enjoy working on (personally), and I am just
hoping to get a little feedback regarding the design, and how it might
fit in with everything else going on in django's guts
(philosophically).  I also understand that this isn't something for near
versions of django, but rather the distant future.

Here's where the pin dropped:
* The jQuery used by the admin site is conjured using the no conflict
option and is relegated/isolated to it's own namespace (excellent).
* There are many projects/apps out there that also rely on jQuery - they
also "bundle" the framework, but may not be quite so quick to play nice.

In my case, I noticed that when I added a few jQuery-enhanced form
widgets to a form in my admin site, it resulted in 3 instances of the
framework being sourced in the document head.  Although, this is
actually ok for the most part in terms of operation (so long as the
scripted events that come with each widget are bound to the dom before
the plugin of origin gets wiped by the next sourcing of jQuery), it's
far from ideal.

There are a myriad of ways to skin this cat, be it a simple
recommendation to adopt  the use of  django's jQuery and a template tag
to provide access to the appropriate script tag, or something more
structured/engineered/formal 

My goal would be to provide app developers with scaffolding to add
javascript/css resources to the rendered view in a non-competitive way. 
I'm thinking in terms of a template tag that works along the lines of {%
include %}, but for script and link tags, allowing folks to add scripts
with an optional way to influence the position in the "stack".  A
similar interface would also be provided for form media, and perhaps
some kind of helper or shortcut for ease the addition of these scripts
from our view functions.

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 briefly considered, but started
foaming at the mouth as a result.
I've also considered the fact that the reaction here might be, "just
don't - leave it all in the individual's hands".

In closing... don't hit me!

Regards,
Owen Nelson

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.