Hi Tom,
This is a great question because it addresses something every web developer needs to know before selecting a web framework, and that is, how reusable will the application code be?
The component-oriented approach found in both of the aforementioned Apache projects is a great way of making sure your application code is capable of being reused in other projects and sometimes in the same project but in different ways. Merb as a framework has also put a huge amount of importance on staying modular, and this certainly has bought its application developers the chance to reuse their code often. We never went so far as to call Merb itself a component-oriented framework, but there are two specific architectural features that might just convince you that it in is.
These are slices and parts. The first of these, the Merb slice, allows developers to extract and encapsulate full segments of an application, including models, controllers, views, tests, helpers, and other assets, into a Ruby package that can then be mounted by various host Merb applications. Classic examples include the Merb auth password slice that can handle your application's login functionality. One nicety of Merb slices is the ability to override and extend their content within the host application. In other words, if you didn't like the default templates from the Merb auth password slice, you could easily override them with view templates in the host application without modifying any other code. The second feature, Merb parts, is also seemingly critical to a component-oriented approach. However parts have never gotten as much attention as did slices, and while I have a theory as to why, here's first a run down of what they do. Each Merb part is structured in just the same way as a regular controller, but they don't directly handle requests. Instead, they are called upon by other controllers and can be embedded within views. This effectively brings the power of MVC to HTML fragments. Thus, if you wanted to make a widget that would appear on a variety of pages, a part could allow you to avoid redundancy by localizing it in an conveniently embeddable controller.
But why exactly use Merb or Rails instead of Wicket or Tapestry? To be honest, the feature set behind all of these frameworks is quite solid and so the final decision most likely becomes a question of Ruby versus Java. And while each language possess its own strengths, it's always a tough call. Right now, I'm in the process of developing a new framework to ease that pain, but since that's not the topic of this
thread and since the framework is still vaporware, I'll just bait a link for posterity:
http://crackframework.com.
Anyway, why do Merb slices get all the glory and not Merb parts? Here's my take: while each of them represent a successful means of modularly piecing code together, the web (at least in its current state) favors the aggregation of services over the composition of components. In other words, a page where a service return an widget via a Ajax request is nearly always preferable to a widget that can only be retrieved when tunneled through a parent request. Slices lean more the way of services, and thus steal all the limelight.
Best,
Foy
