-
Notifications
You must be signed in to change notification settings - Fork 3
Reasons
neoneo edited this page Jan 29, 2012
·
8 revisions
Why was CFlow developed? There are already so many other frameworks around. No one needs this!
Could be. And its 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.
- Some frameworks depend on other frameworks, such as ColdSpring. ColdSpring is very cool, but for some reason I don't like it so much. I don't want it as a dependency. Of course, if you are a ColdSpring fan, CFlow doesn't hold you back.
- Often I see 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. Sometimes I want HTML, sometimes JSON, for instance. If you have a method with a sizable chunk of code that is tightly coupled to the HTML view, you have a problem. The only solution that pops up is moving that chunk of code in another private method and call that from the spots where you need HTML or JSON. That would work, but it's far from elegant in my opinion. 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. That should be enough reason to develop anything, I suppose.