Reasons

Why was CFlow developed? There are already so many other frameworks around. No one needs this!

Could be. And it's probable that this framework will not be adopted by the ColdFusion masses like Fusebox or Mach-II. In the end, this is not important to me. I was not satisfied with the frameworks I looked at, for different reasons.

• For some frameworks the learning curve was too steep for me. I don't know if the learning curve for CFlow is steep for other people, but the concept feels very natural to me. I hope to you too.
• Some frameworks have a lot of features that I don't need. I like it if something does what I want, not more. I just wanted a framework for handling requests.
• I didn't want dependencies on other frameworks.
• In some frameworks it's practice that controllers decide which view to use. In my opinion, that's too much coupling. Yes, in MVC the controller knows about the view. But MVC is originally a client side pattern, it was adapted for the server side later. On the client side, you have UI components (the views), that have controllers. In fact, the controller is a strategy, as in the strategy pattern (read the section about MVC in GoF), it sort of lives inside the UI component. On the server, it's the other way around. First you get a controller, and later on you render output. Often you don't exactly know which output. If the client is a browser, you'll want to serve HTML, if it's a remote program using your API, you'll want to serve JSON, for instance. The controller shouldn't have to know that. It doesn't know those internals in the client side version of MVC either. Over there, the controller talks to an interface. On the server you could do that too, but then the controller still decides if and when a view is rendered. I think it's better to try to completely remove the coupling between the controller and the view, on the server side.

Of course, complaining about other people's work doesn't help. I found the concept of CFlow compelling and elegant, and it was fun to develop it.