Reactor is a powerful tool which helps accelerate development. However, it is not a panacea. It can not be (and will never be) everything you want it to be. Here are some things that Reactor is not:
The Ruby on Rails framework has garnered a lot of interest in recent history, especially in the ColdFusion community. Rails is a framework used to rapidly build applications in the Ruby language.
There are two major components to the Ruby on Rails framework that most people are familiar with:
In particular, Ruby on Rails is famous for the Active Record design pattern. Like Ruby on Rails, Reactor is a code generator. However, the processes used by Ruby and the actual generated code are quite different from what Reactor generates.
For example, Ruby on Rails, which is an MVC framework, generates a whole set of controllers for your application. Reactor is agnostic to your application’s overall architecture. You can use Reactor with your own framework, Model-Glue, Mach-II, Fusebox or even without any framework at all.
One of the most widely touted features of Ruby on Rails is its ability to generate “scaffolding” for your applications. Scaffolding creates simple pages which allow you to create, read, update and delete your database objects. The scaffolding is customized by the developer.
Reactor does not do any sort of user interface generation and it never will. It’s possible that someone could choose their favorite ColdFusion framework (such as Model-Glue) and create a scaffolding program which implements Reactor and that framework. However, that’s beyond the scope of Reactor.
Note: The 2.0 version of Model-Glue uses Reactor and ColdSpring to bring scaffolding to ColdFusion.
One Other Difference
Lastly, the Rails framework relies heavily on convention and shuns XML configuration files. Reactor (arguably) doesn't rely on convention and uses a simple XML configuration file to define relationships between database objects.
Reactor was, in fact, inspired by a lot of the hubbub around Ruby on Rails. However, this does not mean that Reactor has all of the functionality or Ruby on Rails – nor does it try to.
Reactor will not walk your dog. Reactor will not clean your bathroom. Reactor does not slice and dice nor make Julian fries.
Reactor does not do everything you need it to. It can’t. (How could it?)
When you’re working with Reactor you’re going to have to customize some objects to get them to do what you want. Reactor tries to make this as easy as possible.
Keep in mind that the purpose of Reactor is to reduce the amount of tedious, repetitive and error-prone work you’d have to do by hand otherwise. It allows you to focus on what makes your application unique.