Rails "components": I do not think that word means what you think it means.

Right now I have 2 gigs. One is a java gig where I am working on an application I helped develop about two years ago using Tapestry. The other is a Rails gig. This has given me a good opportunity to compare and contrast the two. So far my experience is that I love the Ruby language and don't want to go back to doing Java except when/if I need to to pay the bills. But Rails I'm not as sold on. Mind you I'm not here to bash on Rails, there are some great things there and other people have done a fine job of praising them. But there are some things I definitely miss from Tapestry, and the most significant one is components.

Now when I say components I don't mean that abomination they stuck in Rails and then deprecated. I mean "real" components in the style of WebObjects, Tapestry, and other frameworks in that lineage. To qualify as "real" components in my mind means 3 things:

1. Reusable view and controller logic.
This is the easiest and this is I think what the deprecated Rails components thing was attempting to address. I've seen several other attempts to do this in Rails with varying degrees of success. I think the Presenter pattern being bandied about is essentially another attempt to have this same aspect of "componenty-ness".

2. Composability.
Components should be able to be composed out of other components. I haven's seen something in Rails that did this well yet. It could be out there, but if it is I haven't seen it. And this is also where it gets a little controversial. From what I've seen, DHH and rails core seems to believe that "high level" component reuse is either not possible or worthwhile. Having seen it absolutely work and work well in Tapestry I have to respectfully disagree. The Tapestry Palette and Table components are both "high-level" and reusable on multiple projects to great affect. However even the discussion around component reuse seemed to me to be framed incorrectly, as it seemed focused on components being reused between applications. This is certainly possible, but I find much greater levels of component reuse within an application.

3. Binding.
This to me seems to be the most neglected feature of components, but in my mind is perhaps the most important. This is simply the ability to say something like "the value property of this text field is bound to @person.name". This should result in me being able to access @person with the name already set. I shouldn't have to touch the params hash at all. This would get rid of what I see as an imporant non-dry part of Rails. For example, why should I have to say in my view:

text_field "person", "name"

And then in my controller:

@person = Person.new(params[:person])

With binding I wouldn't have to.

The other place binding comes into play in component frameworks is events. Not only properties support binding, but events do as well. For example, a Button component could have a block bound to the "onlick" property. The framework then manages and abstracts away all the details of HTTP, etc.

I guess that's really what I miss: with a good component framework (and not all of them are) I feel like I am working at a higher level of abstraction. When building reasonably sophisticated web applications, I really miss that. With simple web sites, I don't so much.

So where am I going with all this? Well, I've been thinking about these ideas a lot since I started doing Rails and talking about them with my pairmate. Recently the ruby-component-web-frameworks Google group has been getting active again so I thought I'd blog about my ideas. I've started doing a little code experiment to see how it might look to implement some of these ideas as a Rails plugin. It seems not too difficult so far; it never ceases to amaze me how much I can say in so little Ruby code. When we have an SVN repo setup I'll share what I have but it's just an architecture spike right now.