About the MVC part of Merb, I wanted to know if Merb is or can made "component oriented" ?
In the Java world, the most powerful web frameworks are component oriented (Wicket: http://wicket.apache.org/, Tapestry are the best of them).
I mean that these frameworks rely on separating the parts of a web page in components that can easily use, test, maintain and such.
The main idea is to divide the responsability.
Some of the main advantages of a component oriented framework are the maintainability (a component has it owns resources, like css, images, languages files) and the testability (a component can be isolated from the outside; seems like a Unit test).
So will Merb/Rails be Components frameworks someday ?
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.
Foy, can you help me understand how slices are different than regular Rails plugins, where I get MVC +tests?
I also have a question about components. Apparently the Rails core team tried, then abandoned components at some point. Do you know why this is?
A general comment about components, specifically in the Java space. I've had a tough time with component driven frameworks simply because they lock you into "that" framework (aka JSF components cannot be used in a struts or simple servlet/jsp app). This meant that all of our cool components would need to be re-factored to work when we introduce a new framework (something that happens surprisingly often in the Java space). The other issue we've found is where the components themselves were lacking in either quality or features (e.g. I've been working on an accessibility project where JSF components are... weak, to say the least, yet difficult to workaround).
What I'd like is a component that does what it's supposed to do, follows standards, can be extended (reasonably), and if I have to write a custom piece of it (let's say implement a custom view, or add a small bit of functionality), that it's not a royal PITA.
Would you say slices are open to this kind of treatment?