Beyond Java - Bruce Tate [71]
Action Pack
Action Pack deals with requests in two parts: the controller and the view. Requests come into Action Pack through a dispatcher. The dispatcher routes the request to a controller, which invokes any model logic and sends the request to a template-driven view system. The template engine fires the Ruby template, which may execute Ruby code, and returns the resulting HTML to the browser. The flow, shown in Figure 7-3, is reminiscent of Struts. There are a few differences. For example, the controller has a group of actions, instead of encapsulating each action in a different class. If you wanted to refactor, you'd let actions share methods.
Figure 7-3. Ruby on Rails is actually made up of several existing frameworks, most notably Active Record and Action Pack
The Action Pack splits the request into a controller part and a view part. With Rails, a whole lot happens automatically. In some ways, that's bad. You can't see all the methods or the attributes on your class, and you don't even know what they are unless you look at the database. In other ways, it's a highly productive way to work. You can change your model, schema, and view in many cases just by adding columns to the schema. Let's take a fuller look at the capabilities of Action Pack.
Capabilities
Action Pack goes beyond simple request processing. It contains many capabilities that make it easier to develop web applications. I'll touch on some of the major capabilities here.
As you've seen, Action Pack uses Ruby as the scripting language. Java developers frown on embedding Java into a JSP, but I'd suggest that code will be in the view regardless of whether it's in Ruby. Early on, some vocal zealots overreacted to the early proliferation of Java scriptlets and decreed that MVC means "no code on the page." Many Ruby developers believe that code that is concerned with the view (and only the view) does belong on the page. Burying Java code in a custom tag only complicates and confuses the issue.
Ruby provides a far friendlier scripting language than JSTL tags, for example. Like servlets, Action Pack lets you attach filters for things like authentication. Action Pack also handles some convenience design elements, like automatically paginating your result sets and providing navigation links.
Action Pack also has some features that make it easier to build components, like helper classes (to render a date, for example), a layout sharing feature (similar to Tiles, if you're familiar with Struts), intracomponent communication, and pretty good Ajax integration. Like Struts and Spring, Action Pack provides good support for building and validating forms.
You'll need to manage your solution, and Action Pack builds in some features to help. It enables logging, caching at three levels (page, action, and fragment), and benchmarking support. Developers can use integrated support for unit testing and debugging. It's not as powerful as Struts in some ways, but it's much simpler, and highly customizable.
The Essence
So, Rails is not a toy, and it's not a gimmick. In my opinion, Rails represents a significant advance in the state of the art. You've probably seen frameworks like this one solve the database-with-UI problem in several different ways:
Object-oriented development frameworks are flexible and robust. They're usually at a lower abstraction level, so they may not be as productive. You can use them to create flexible, robust, and powerful applications, but you're going to pay for it with productivity.
Quick compromise frameworks trade conventional wisdom and sound design for implementation speed. PHP and Visual Basic, for example, compromise by trading design wisdom (frameworks should encourage separation of model and view logic) for development speed.
Code generation frameworks