Blogging My Experiences with ColdBox
So a week, or so, ago I suggested I might start blogging about ColdBox and my experiences with it. I got a pretty good response, so I am going to go with it.
I am not sure yet what this is going to turn into. Whether it will be a few blog posts, or a series, or just what, is unknown. For now I am thinking of just creating a new, simple application and walking through the steps that I would take build it. Not too dissimilar from what Ben Nadel is doing with his OOPhoto project. But mine will be focused on using ColdBox to build the application.
The posts I will be writing are about things that I have learned. I am not 100% certain that they are right or the best way, so please keep that in mind while reading. I am always open to criticism and correction, so I welcome those from the experts and experienced.
I am not an expert in Object-Oriented programming, ColdBox, Transfer, ColdSpring, MVC, or Service-Oriented Architecture. These are things I am learning about and I want to shared those experiences.
So, that said, what am I going to talk about. Damn it, that's a tough questions. OO, MVC, Frameworks, and all that goodness is such a HUGE set topics that it is difficult to know where to begin. Especially since some are prerequisites of others.
Additionally, building the simple application using only ColdBox makes it much less simple. So, I would want to, at least, use ColdSpring to ease the process. But then am I cheating you, and me, out of learning something(how to manage dependencies without ColdSpring) important?. I'm sure that I would struggle with managing dependencies without ColdSpring.
Well, I am going to have to think about this a bit. Please feel free to comment with suggestions and requests. For now, I am going to plan to just start building the app with ColdSpring, and make the assumption that readers have a basic understanding of OO concepts. I will try to make a list of prerequisite knowledge for each post.
Man, I hope I don't embarrass myself with this ;)






That is a tall order. Developing OO applications without some sort of DI is a pain, and even demonstrating that in a small area would take more time than I am willing to give right now.
I can tell you this, anytime that you see us using ColdSpring in the applicaiton, you can imagine, instead of using getPlugin("ioc").getBean(), that instead we would need to use createObject() to first create each of the dependencies that the bean that we want needs, and then we would need to use createObject() again to create the object we need, and then use setters to pass in each of the dependencies. So instead of having something nice and clean like this:
<cfset var userService = getPlugin("ioc").getBean("userService");
we would have something like this:
<cfset var userService = createObject('component', 'model.user.userService) />
<cfset var userGateway = createObject('component', 'model.user.userGateway) />
<cfset var userDAO = createObject('component', 'model.user.userDAO) />
<cfset userDAO.setGateway(userGateway) />
<cfset userService.setDAO(userDAO) />
<cfset userService.setGateway(userGateway) />
And that is just for a couple of objects with a couple of dependencies. You can imagine the mess if there were more dependencies, or worse, circular dependencies.
I hope this helps you visualize what you are getting from ColdSpring.
You can also look at ColdBox's new Model Integration tools that also serve as a DI framework if you don;t want to use ColdSpring.
http://ortus.svnrepository.com/coldbox/trac.cgi/wi...
You can also check out this ColdBox SimpleMVC Demystified post that demonstrates some of this.
http://blog.coldbox.org/post.cfm/coldbox-simplemvc...