From Loud Thinking:
One of the clear goals for Rails from the start was to stay at the infrastructure layer. I didn't want Rails to succumb to the lure of high-level components like login systems, forums, content management, and the likes.
[The case against high-level components]
I agree. But I'd like to add that the case is not against component systems / architecture, it's just against this idea that one-bulletin-board-fits-all is how component architectures should work. Components work best when they're small grained and interchangeable. Yes - being able to nicely integrate a complete bulletin board system into a customers site is a nice thing to have. But in my experience, the work often required to do a good integration in a lot of these systems seems to be about equal to writing one from scratch. This is not always the case - I was able to integrate two very different systems with different histories a few months ago, but there were a couple of advantages there: they were both written in house, and both had put some effort towards just enough customization and control-layer separation that it could work.
I've been using a system that a colleague has been building in house, and it's basically a chain of fine-grained components that operate on data as data flows to and from storage. As a result, we have a system that gives us so much more than most generic form display / validation tools for presenting and working with data and user input, more flexibility than most object-relational mapping systems, and tight granular security. There are parts of the system that require a fair amount of work, most of it in configuration (lots of XML sit-ups, as the Rails community might say). But in my experience so far, once the components are wired together they've proven to be very dependable. Once one part of an application is complete, it rarely needs touching. It's difficult for other things to interfere with it. Built around the concept of "no alarms and no surprises," magic is forbidden. Explicit is better than implicit. And the components are given only enough information to do their specific job - whether it's validating input, presenting data on screen, or preparing data for storage.
I first wrote up how such a system might work a couple of years ago in my post "Component-Relational Mapping?" and that particular system has suited me well in a few projects. This other system is simultaneously a much larger (it stands alone with no requirements on Zope or anything else, and doesn't even place any real requirements on how one stores data) and a much simpler system (the core concepts are really simple). Applications built on it are a good example of applying small, tough, and smart components to get jobs done.