Skip to content


Subversion checkout URL

You can clone with
Download ZIP

Why use Rango?

botanicus edited this page · 23 revisions

This page is up to date for Rango 0.1.

Rango Philosophy

Rango doesn’t force you to anything, it’s up to you to do the design decisions. We believe in simplicity and lightweight tools for one purpose rather than one big bloated everything-solving magic beast.


Rango loves Rack, it uses it as much as possible rather than hide it as some other frameworks. Thanks to Rack, Rango is incredibly powerful: there is huge amount of Rack middlewares you can use, you can choose your favourite router, you can use amazing Warden for authentication, whatever!

Template Inheritance

Template inheritance is simple, but very powerful concept of handling base template/child template. It’s way more powerful than the standard layout/view, because you can inherit in a chain, like base.htmladmin/base.htmladmin/posts.html, so you can have one site-wide base template and one for each subsites (usually admin & user part) which will inherit from the generic base template.

It has very nice usage with AJAX, you can do extends "base.html" unless request.ajax?, so if the request is AJAX, it renders just the child template, so you can just replace this part of page through your JavaScripts.

And the fun just begins, you can inherit not just a string with some HTML, but whatever value, so you can pass arguments via the inheritance etc! Check template inheritance chapter for more details!

Bundling via Bundler

Every single bundling solution I’ve been working with sucked. Until Yehuda Katz wrote Bundler. Now everything just works, it handles environments properly, it provides working tools for installing dependencies, it can even download source from Git repository and create the gems. And the best is, you don’t have to use RubyGems in runtime!

HTTP Errors Handling

There is a lot of ways how you can handle exceptions in MVC pattern. In Merb you have special Exceptions controller, Rails prefer to keep it in one controller. Rango isn’t opinionated, so you can set how it will be handled just by definiting Rango::Controller#rescue_http_error, resp. Rango::Controller#render_http_error. You can implement both Merb and Rails-like errors handling in a few lines of code!

Generic Views

If you have some repetitive tasks which can be shared across more controllers, you can use generic views to handle them. Classical example is when you just want to render a template. There is quite common that guys just have bunch of methods which do just render. This is bad practice, and thanks to generic views, the only thing you have to do is route some URL to Rango::GV.static.

This is how generic views works in Django. But in Rango, you can do more. You can for example include Rango::GV in your controller and then use filters or even super to extend the view.

Easy to Write Custom Generators

Thanks to amazing simple-templater, it’s really easy to write your custom generators or execute custom hook before or after the generator runs. Lets say you are not very big MIT fan, and you want to use Ruby license instead.

The only thing you have to do is create ~/.simple-templater/rango/project/content/LICENSE file containing the Ruby license. Easy, right?


[0.2] Out-of-the box Pupu integration. Pupu is framework for writing assets plugins and there are already bundled many of useful javascript libraries and frameworks. You like MooTools, ya? Just run pupu install mootools and you’re done!

[0.3] Pancake integration: Pancake is basically a glue framework for connecting multiple Rack applications. After the integration, I’d like to have each application as a gem which can use other Rango/pancake applications, so everything can be distributed as gems and therefore installed via Bundler. Such application shall have not just its own controllers and models, but also templates and assets.

Something went wrong with that request. Please try again.