Asset Management

[afknapping]

now that there are "assets" and conventions on how the assets are to be placed within themes etc, i'd just like to throw in that the idea of the asset pipeline in general makes total sense to me. depending on how it is implemented, it could solve two problems at once:

1. "use any templating syntax for input you want" (eases development)
2. "have assets packed, minified and fingerprinted at deployment" (eases production).

(as rohuh is in beta, nr 1 probably has the higher priority)

although things like tilt and/or sprockets add dependecies, in the end you would have to give me a reason why to switch from my current blogging-engine to a new one. lowering hurdles and stuff.

so, my point is: "use any templating syntax for input you want out of the box" might be an argument for people to switch to rohuh, who (like me) are not able to easily build their own rendering routines in ruby.

[plusjade]

@filtercake

Asset Management

I think something like sprockets is a great addition which I expect to add in as an optimized user experience. I'm not too familiar with how it specifically works (haven't looked into it) but I'm assuming I would add it in as an officially supported plugin. There should be an asset packager available to all languages, with the API just being the file extensions so this will work fine.

Arbitrary Templating Languages

"use any templating syntax for input you want out of the box"

First some clarification. In ruhoh there are two stages to processing content:

1. Templaters take a templating language like mustache, liquid, erb, and render it's result. The templating language necessarily interfaces with ruhoh's database to output the data.
2. Converters parse a markup language like markdown, textile, restructured text.

Converters

I see that tilt supports both kinds of concepts. For converters, this makes sense -- the more converters the better. Actually tilt primarily supports converters so this may be worth looking into.

Templaters

One of ruhoh's core goals is a language-agnostic API.

In terms of templating, however, we run into the obvious problem that very few templating languages are language-agnostic. In fact most popular templating systems are just embedded code: .erb, .eco, .php.

A good example of a project that supports tons of templating languages is DocPad. While "chose your own templating language" seems like language freedom, I'd argue that it would be very hard to keep any kind of design consistency. How would you install themes?

The problem is we basically guarantee fragmentation.
It will be far to easy for a developer/designer to contribute (haphazardly) to ruhoh in their native language. Want a tag cloud? Fawk it just embed the straight ruby query using .erb. While it's convenient, it's not in everyone's best interest. Consider the alternative where the tag cloud is implemented using a mustache method. The contributor can still code in his native language (supported by mustache) but the API requires him to use {{tag_cloud}} to output the necessary feature. Now we can go down the line in each language, implementing the tagcloud, but having one solid common interface point: {{tag_cloud}} that a designer can reliably use.

Am I being too stubborn? Also for fwiw, I think DocPad is freaking robust as hell. Too robust, I've actually never even tried setting it up because the documentation overwhelms me -- I don't want ruhoh to be like that.

[afknapping]

ah, thanks for taking the time to write that up.

so what i really meant was "use any converter language you want" – i got that part with moustache and that should of course stay the way it is. if you don't mind, i will throw some word definitions in the wiki sometime.

totally agree on the documention part. i don't need long, well-formulated, haha-funny texts – i often miss short and simple lists on how stuff works and what it is called what so there are no misunderstandings.

sprockets: if you are looking for the "how it works"-part from the user point of view, this would be the part of the docs: https://github.com/sstephenson/sprockets#the-directive-processor.

[tkellen]

Please don't use sprockets. Use rake-pipeline.

[plusjade]

@tkellen can you give a quick pro/con argument and also verify that you are talking about this rake-pipeline

[tkellen]

Rake-pipeline is fast. It saves deltas for each step in the asset compilation process and can recompile from any point when a file changes, making it extremely fast. Sprockets isn't that smart, it recompiles the entire asset pipeline any time something changes. Making matters worse, it is slow too (one benchmark: https://github.com/mislav/sprockets-perf). Think several seconds to reload a page in development when one javascript file changes.

Rake-pipeline is very extendable. Not that you'd want to, but you could likely write most of ruhoh itself as a rake-pipeline filter (some example filters: https://github.com/wycats/rake-pipeline-web-filters/tree/master/lib/rake-pipeline-web-filters). Sprockets is very implementation specific. Extending it to do new things is really hacky.

Rake-pipeline offers a nice DSL (see https://github.com/tkellen/sinatra-template/blob/master/Assetfile) for configuration. Sprockets uses file comments for configuration, this spreads the control of your asset pipeline into multiple files and severely limites flexibility in processing.

[plusjade]

@tkellen, @filtercake @ben-biddington, @rlemon, @davejlong after taking a look it does seem like rake-pipeline is better suited for ruhoh's "universal" approach if you will. I like the idea of a separate configuration file rather than inline comments as well. I'm curious to know why rails went with sprockets.

Primarily ruhoh needs to control the asset-pipeline as you say. Rather than have themes hardcode stylesheet and javascript links, there should be an {{assets}} mustache helper which will serve the correct script and stylesheet urls for the given page in the given environment. e.g. serve every file in development mode, but intelligently serve the packaged files when compiling.

The crux of the matter is ruhoh needs to handle this pipeline in a language agnostic way.

At the moment I've worked out a system where all themes specify scripts and stylesheets to load on a per-layout basis via a theme.json file. Example theme.json

Ruhoh parses this, checks for defaults, etc, and provides the data like this:

{"default"=>
  [{"url"=>"/assets/fluid/stylesheets/bootstrap.min.css",
    "id"=> "/Users/jade/Dropbox/active/ruhoh/plusjade.ruhoh.com/themes/fluid/stylesheets/bootstrap.min.css"},
   {"url"=>"/assets/fluid/stylesheets/style.css",
    "id"=> "/Users/jade/Dropbox/active/ruhoh/plusjade.ruhoh.com/themes/fluid/stylesheets/style.css"}],
 "post"=>
  [{"url"=>"/assets/fluid/stylesheets/example.page.css",
    "id"=> "/Users/jade/Dropbox/active/ruhoh/plusjade.ruhoh.com/themes/fluid/stylesheets/example.page.css"}],
 "widgets"=>
  [{"url"=>"/assets/fluid/widgets/google_prettify/stylesheets/desert.css",
    "id"=> "/Users/jade/Dropbox/active/ruhoh/plusjade.ruhoh.com/themes/fluid/widgets/google_prettify/stylesheets/desert.css"},
   {"url"=>
     "/assets/fluid/widgets/table_of_contents/stylesheets/table_of_contents.css",
    "id"=> "/Users/jade/Dropbox/active/ruhoh/plusjade.ruhoh.com/themes/fluid/widgets/table_of_contents/stylesheets/table_of_contents.css"}]}

(The concept of widgets is new. It's an interface for defining snippets+javascripts+configuration in a modular plug-n-play fashion. Suffice to say widgets can register javascript dependencies while themes can provide default styles on a per-widget basis)

With the provided data, mustache is able to output the correct urls based on the given page layout, defaults, and environment.

I need help vetting this implementation.

1. Is specifying stylesheet and javascript load dependencies via a json file an acceptable/good user experience?
2. Is the generated data hash a sufficient interface for accomplishing what an asset manager/packager would need to do?
3. Any suggestions?

[matteolc]

Could we integrate HAML in the asset pipeline? https://github.com/infbio/haml_assets Or is it breaking the language agnosticism

[plusjade]

@tkellen heads up, I'm having too many problems with rake-pipeline. I tried the base example here: http://rubydoc.info/github/livingsocial/rake-pipeline/master/file/README.yard and it does not work. I finally got it to work by cloning your sinatra-template and magically figuring out the gem dependencies I need (as per your gemfile).

The next annoying thing that popped up was the compass dependency....why do I need the compass gem to parse sass? I tried to reimplement the sass parser from web-filters gem to no avail.

Also in your Assetfile you are using match statements within the include block, however all documentation everywhere does not have them in the block. Yours works, but I'm stuck thinking why in the hell are the docs so wrong?

I still don't have it working for the use-case I need.

All I want to be able to do is parse files based on their extension in a completely opt-in manner. In other words I don't want ruhoh to depend on 84 gems like sass, compass (wth?), coffee-script, and so on. However a user should be able to use these if he wants.

The workflow would be:

1. Add gem dependency to your gem file.
2. Add appropriate extension to your files. (style.css.sass)

That's it! There should be no other configuration on the user's part.

Sprockets works exactly like this. I have to admit I got sprockets working just now in literally 3 minutes. I really don't like the require-directives-as-comments-thing sprockets has going on (really odd), but wow, it works!

I really wanted rake-pipeline to work, but unless you can show me the 1 minute presto it works approach I'm going to have to go with sprockets.

[tkellen]

@plusjade Sorry, I haven't touched rake-pipeline in a few months. Perhaps @wycats or @dudleyf would have time to weigh in on this?

[plusjade]

Ruhoh 2.1 officially supports sprockets

http://ruhoh.com/docs/2/asset-pipeline/

[peck]

Does the asset pipleline as currently implemented support using haml/etc for defining layouts?

I've added the requisite "gem 'haml'" to my Gemfile, and tried creating a default.html.haml, but get the error "Layout does not exist: default", and when renaming that file to default.haml the contents of the file are rendered without going through the haml templating engine.

Scss files work file so it seems that the sprockets engine is being used correctly, but otherwise I'm at a loss.

[plusjade]

@peck you are right in that the full sprockets environment is loaded so it can easily compile haml, however in ruhoh sprockets is attached specifically to the javascripts and stylesheets assets. The layouts collection does not interface with sprockets. Also to your specific problem, I think the layouts finder is not setup to find files with multiple extensions a la sprockets style. It should find them so if it doesn't it's a bug.

I actually use haml at work and it's a bit annoying to go back to straight html =p. The main issue with supporting haml is you necessarily are supporting ERB, which ruhoh does not advocate. I think it's theoretically possible to use mustache in conjunction with haml, is that right?

Finally, ruhoh likes the whole "language agnosticism" of mustache and the ability to drop in ERB would probably be really tempting to people =p

However in thinking about it, I'm not against supporting haml since ruhoh is ruby, and haml is useful for the rubyists (loaded as a plugin). How about you open a feature request for haml support and I'll take a shot at it in my spare time. Although many other things should be prioritized before that so we might just get another user onboard with giving it a shot.

[peck]

@plusjade thanks for the quick response. I've actually started using slim lately and love it, not quite as terse as haml, but with most all of the benefits and some mustache style templating built in. Mentioned haml in my post since I figured more would be familiar with it.

As you mentioned it probably should be prioritized lower, but may be nice to have on the roadmap either way