Friday, April 16, 2010

ColdMVC: Routing

At the most basic level, all a web application does is accept a user’s request, process some data, then send a response back to the user. Figuring out what and how the application should process is what routing is all about.

A typical URL inside a ColdMVC application will look like following:

http://myapp.com/index.cfm/product/show/1

Using pattern matching defined in a config file, ColdMVC is able to determine the appropriate controller and action that should be executed for the request, as well as any other parameters that should be populated into the request. For example, the previous URL would result in the show method being executed on the ProductController, while also setting params.id to “1”. This is because the incoming request, “/product/show/1” matches the default pattern “/:controller/:action/:id”, defined inside /coldmvc/config/routes.cfm.

You’re able to create your own custom routes inside your application’s /config/routes.cfm file. Custom routes are especially handy when creating user-friendly URLs. For example, you could create a pattern that routes anything matching “/user/:name” to UserController.show(). Here’s what that route would look like inside the routes.cfm config file:

<cfset add("/user/:name", {defaults = {controller="user", action="show"}}) />

ColdMVC offers several other features for handling incoming routes, such as parameter requirements, default parameters, and computed parameters, that I'll cover in more detail in future posts. However, knowing just the basics should cover most routing scenarios.

Recognizing routes makes up only half of routing. Since it’s possible for ColdMVC to consume URLs that match a pattern, its equally important that ColdMVC is able to generate those same URLs as well.

The easiest way to generate a URL inside a view or a layout is by using the #linkTo()# plugin. This method can accept three arguments: a struct of parameters, a querystring, and a name. For most links in the application, you’ll only need to specify the parameters, which typically consists of keys for the controller, action, and id.

For example, if you want to link to a product’s record, your code might look like this:

<a href=”#linkTo({controller=”product”, action=”show”, id=product})#”>#product.name()#</a>.

If you don’t specify a controller or an action in the parameters and a matching route can’t be found, the router will look again, only this time it will add the current request’s controller and action to the parameters.

There are several more advanced features of URL generation that I haven’t discussed yet, such as named routes and model-based routes, so I’ll go over them in more detail in future posts as well. In the meantime, if you’re curious to see how these features work, take a look at the routes defined for the sample blog application, located at /coldmvc/samples/blog/config/routes.cfm.

3 comments:

  1. I am reading your posts about ColdMVC and think of ColdFusion on Wheels :-) Maybe you should check it out and help contribute to it.

    ReplyDelete
  2. Maybe not?

    http://bears-eat-beets.blogspot.com/2010/02/another-coldfusion-framework.html

    ReplyDelete
  3. @Mike,

    Yeah there are definitely similarities between ColdMVC and ColdFusion on Wheels, simply because they're both inspired by Ruby on Rails (and Grails, in the case of ColdMVC).

    I've played around with ColdFusion on Wheels before and from what I've seen it's a very solid framework. However, I chose to write ColdMVC because I wanted a tighter integration with ColdSpring and Hibernate.

    ReplyDelete