Asset Pipeline

[Sebastian Riedel]

I know a few of you have been working on asset pipeline plugins in the past, but so far none have made it to CPAN. Possible designs have been discussed at length on IRC, and to push this topic a bit further, i've implemented a minimalistic prototype. Perhaps it can serve as an inspiration, or even grow into something more usable.

https://gist.github.com/3927875

For those that don't know what an asset pipeline is, think of it as a preprocessor for your static files that can make your application a lot faster by saving HTTP roundtrips and bandwidth. You just make a list of JavaScript and CSS files that should be concatenated and minified, it will do the rest. Other preprocessing tasks, such as precompiling CoffeeScript and Sass are also possible with additional plugins.

There are still many open design problems, but should those be solved, is there any interest in having this functionality in the Mojolicious core distribution?

--
Sebastian Riedel
http://twitter.com/kraih
http://mojolicio.us

[pierrick dintrat]

hi,
I actually move my website from Catalyst to Mojolicious and it's the one thing i dont know how to do with Mojolicious.
I would love to see this functionality in the Core. I will have a look on your prototype quickly 

Pierrick DINTRAT

2012/10/22 Sebastian Riedel <kra...@googlemail.com>

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

[Ben van Staveren]

Yes. :D

--
Ben van Staveren
phone: +62 81 70777529
email: benvans...@gmail.com

[Roland Lammel]

Yes, definitly.

Having it in core will save my reinvent-the-wheel roundtrips for moving development stuff to production where I usually take care about these things (really at the last moment before moving to production).

+rl
--
Roland Lammel
QuikIT - IT Lösungen - flexibel und schnell
Web: http://www.quikit.at
Phone: +43 (676) 9737845
Email: r...@quikit.at

"Enjoy your job, make lots of money, work within the law. Choose any two."

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To post to this group, send email to mojol...@googlegroups.com.

To unsubscribe from this group, send email to mojolicious+unsubscribe@googlegroups.com.

[Sebastian Riedel]

> There are still many open design problems, but should those be solved, is there any interest in having this functionality in the Mojolicious core distribution?

Since there appears to be quite a bit of interest in this feature, here are some of the design problems that still need to be solved and are on top of my list atm.

1) How should pre-filters work that need to be applied to the indovidual source files before they are concatenated? These would mostly be compilers, like our EP renderer, CoffeeScript, Sass and the like.

- The most popular solution so far would be a nested data structure that represents the entire pipeline.

asset 'app.js' => [['*.js.ep' => 'ep'], '*.js'] => 'jsmin';

- An alternative would be recursive assets.

asset 'coffee.js' => ['*.coffee'] => 'coffeescript';
asset 'app.js' => ['*.js', 'coffee.js'] => 'jsmin';

2) Where should the asset source files be stored? This is a bit tricky since we need to share the DATA section with the static dispatcher and renderer.

- Most popular solution here is to just consider all static files and templates potential asset source files indiscriminately. Their extensions would only be used for finding (like in the glob above), but would have no meaning attached otherwise, MIME types are based on the target file and filters on the pipeline. A big advantage would be that we can access all static files and templates shipping with plugins for example.

3) How should we decide which filters are only necessary for production and should be disabled during development?

- A simple blacklist is currently the most popular solution here.

app->pipeline->development_filters([qw(ep coffeescript sass)]);

- Alternatively we could also split all filters into categories, like compressors and compilers.

4) What should be the name of the helper (and possibly Mojolicious::Lite keyword)? While "asset" sounds pretty good it might get confused with our existing Mojo::Asset classes and related methods.

- We have no alternative name for it yet. The pipeline class will be called Mojolicious::Pipeline, and everything will refer to it as "the asset pipeline".

[sri]

> - A simple blacklist is currently the most popular solution here.
>
>     app->pipeline->development_filters([qw(ep coffeescript sass)]);

Looking at it now, i guess it would make more sense as a whitelist.

app->pipeline->production_filters([qw(jsmin css_compressor)]);

or maybe more neutral

app->pipeline->optional_filters([qw(jsmin css_compressor)]);

[sri]

Since the problems couldn't be resolved, i've basically stopped
working on this feature. If anyone wants to continue and turn it into
a CPAN module, you're welcome to take whatever code you like.

[patric...@gmail.com]

I was curious if this progressed any?  Have any new thoughts developed?  If not, I might be willing to give it a crack.  I think an asset pipeline is inherently important within modern web frameworks.

Patrick

[sri]

> I was curious if this progressed any?  Have any new thoughts developed?  If
> not, I might be willing to give it a crack.  I think an asset pipeline is
> inherently important within modern web frameworks.

Afraid there has been no progress, currently i'm investing all my
spare time in Mango.

--
sebastian