Autoload alternate template engines

+1 I like the idea

I was kind of worried about autoloading the gem during a request, but that would only happen if you were rendering a foreign ext outside your view path. In that case, your a loser anyway.

Do you how much it slows the process down? Cause this is going run alot during dev mode.

Maybe we should also have a logger output for dev mode that says "autoloading gem" or something. Or maybe not.

Is HAML the only gem that has a rails/init.rb at the moment?

This shouldn't slow down the process very much at all. It doesn't have any effect if all your templates have recognized extensions, and even if it does hit autoload_handler_class it's just a hash lookup to realize that the gem doesn't exist. The only time it would have degraded performance would be if someone had a template that had an extension that coincidentally matched a non-template Gem. That doesn't seem very likely, and even then it shouldn't be a noticeable slowdown.

I was under the impression that rails/init.rb was a convention for loading gems automatically. The creating_plugins guide bundled with Rails mentions creating one, though, so there's some sort of precedent.

(from [c044c079ab14487b4410874be2169ab4aa9b8a23]) Revert "Auto-load template handlers based on unmatched extensions [#1540 Autoload alternate template engines state:resolved]"

This reverts commit e8c1915416579a3840573ca2c80822d96cb31823.

Reasons : - ActionPack tests run very slow - Gem.searcher hanging for long time when extension is nil http://github.com/rails/rails/co...