One of the parts of the Rail’s stack that always seemed to confuse me was the
routing. Once you go beyond the simple
resource routing unless you have a bit
more under you’re belt reading and writing routes can be daunting. I would like
to go over just a couple items that I’ve picked up which may prove helpful for
others who need to go beyond the vanilla route schemes.
If you dig into some of the more recent routing documents for Rails you’ll find
some examples using
scope to namespace routes; however there is more you can
do with it then I’ve found in the docs. Scope applies a matching rule and will
allow any matches to trickle down into it’s block for further matching.
For instance, if you have to make an advanced routing decision based on
something in the request besides the just the http verb and the uri, you can use
contraints key. The following route will match
/motd and route it to the
BotsController#motd only if the request headers’ user agent has
curl in it.
A pretty contrived example; however, it helps to put some of these decisions in
the router instead of forking totally different kinds of logic in the
controller. If you have a lot more routes like this that you would like to map
to the the
BotsController you can use scope to do it.
If your logic starts to get a little hairy, or you just want ot keep everything
tidy, you can also pass
constraints an object that has a
matches? method for
Used in the routes: