Yesterday I had the privilege of providing my first consultation job as an instructor on the subject of Coldbox. The team that hired me are at the stage in their project where they're ready to start writing code (database is designed, UML and usecase diagrams are complete, mockups have been created), and they wanted to "experience" my thought processes, the questions I ask myself, my approaches to implementing functionality, and how I troubleshoot as I make my way from an idea to a working app in Coldbox. So, we spent the entire day together building an app from scratch, using Coldbox.
In preparation for the task, I spent the past week investing a LOT of time re-reading the Coldbox docs, experimenting, building out a small sample application that the team and I scoped out beforehand, and making notes about my thought/decision-making processes along the way.
Taking notes about your own personal development process is actually quite interesting and insightful, and since my audience found it useful and enlightening, I thought I'd share a high level view of it with the rest of the community as well. What follows is a bullet point list of how I personally generally go from idea to app.
Let's take a walk in my head, shall we? Don't be afraid.... 
1. let's get the current version of the coldbox framework (www.coldboxframework.com)
2. grab copy of the skeleton app template from the Coldbox framework download (coldbox\ApplicationTemplate)
3. make sure I have a mapping to Coldbox (mine is in application.cfc using this.mappings[...)
4. browse to the skeleton app and make sure that I get the pre-canned "You are now running Renew version 2.6.3..." home page.
5. Now, let's make a grocery list! What do I mean?....
The Coldbox framework (really more of a robust toolkit) does a LOT...which aspects, features, abilities do we want to incorporate into OUR application? Until you know what Coldbox has to offer, you can't answer this question. So, read through the online wiki my friend; open the ColdboxCheatSheet.pdf that comes in the framework's 'install' directory and take a good gander at all of the methods, plugins, interceptors, and other items listed there; Open up the Coldbox.xml.cfm file and just read the different settings that are listed there; Peruse the framework's directory structure, its config files, plugins, interceptors, autowiring, model management, views and layouts, usage of convention. As you learn about each new aspect, think about the app you are building and decide if it is one of the features you want to be sure and incorporate.
For this particular application, here's the grocery list I came up with when considering app features with framework features:
- I will use the built in Coldbox model management as opposed to a third party IOC framework;
- I will not use an ORM framework for this app (though if the project warranted one, I most definitely would!);
- I will be using Ajax so I'll want to take advantage of Coldbox's multiple layout ability;
- I will be using my own security interceptor instead of the one that comes with Coldbox;
- I will not use the environments interceptor;
- I will be sure and enable the sidebar debugger;
- I will make exclusive use of the MessageBox plugin for all system messaging
6. Okay, now I'll take a first pass through my config.xml.cfm file and alter the settings I know about at this point.
- Enable model setter injection;
- add custom settings for my javascript library path, my css path, my images path;
- define the datasource object;
- and enable the sidebar interceptor.
7. At this point, I feel the need to go ahead and create my database table structure and get that to a solid starting point.
8. Let's tweek the default layout and make placeholders for the different components it must organize (header, footer, nav, content, messages, dynamic content area, etc.).
9. Now i want to replace the pre-canned default view with one of my own...my app's own "you are here" landing page. On that page I'm now going to take the time to output lots of global data that I'll likely need to know how to get at later, like the datasource name, the name of the current event, etc. I will use this output as a cut-and-paste reference later.
10. Let's add some security with simulated authentication! Get a basic "login/logout" form to work without actually doing any database calls. The objective here is to just get the appropriate session variables in place, get them added to the Event object at the appropriate time, make sure our events are being intercepted and examined by security code at the appropriate places, and that rendered output is based on authentication status where it makes sense. Once it all works in simulation, add in the needed model objects to perform actual authentication and replace all simulation code.
11. Now I will focus on navigation (if it's anything but simple nav, such as database-driven, hierarchical nav) and ensure that all code is in place to create and output navigation appropriate for the user and state.
12. From here on out, I simply start going down the list of remaining functionality, typically ordered from "least specific" to "most specific", giving all end-user functionality priority over administrative functionality. The easy way to do this is to simply work my way through my navigation items, building out one at a time. To illustrate in more detail how I build out a specific piece of functionality (we'll say a CRUD operation), here's the check list:
- build the handler with basic event functions to handle our nav links
- build out the view page for managing an item
- add a function for saving an item that saves then returns to the calling event
- create a model service for the item...wire it up(using Coldbox's Model Integration feature
- add the model service to the modelmapping.cfm
- wire up the handler, finish up the handler functions that call the corresponding/appropriate service object's methods
In a nutshell, this is my general thought process as I build an app, with emphasis on building a Coldbox app. How does my "to do" list match up with everybody else's? I'd be interested to know!
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
Doug,
Just wanted to express my thanks for the outstanding workshop yesterday. I thought it was extremely informative, and it sure gave me boat loads of confidence to just "jump in the deep end" of ColdBox. You've made me even more eager to get into the development portion of my project (which I believe is just around the corner).
I did receive the source files for the apps you built yesterday and was able to get them loaded up on our server without any problems.
Thanks again and I hope to see you around!
Ryan Jeffords
Senior Web Developer
Thanks for the tips. I did have a question about 1 item in the list:
"I will not use an ORM framework;"
I know that ORMs are not the silver bullet, and it really depends on the project. I was wondering if you never use an ORM, and how come? I'm just looking for another developer's perspective.
-Dutch
In this example, when I said "I will not use an ORM framework", I definitely did not mean ever, I simply meant for that particular project. I really love Transfer, actually, and if I feel that the shopping list for the project at hand could benefit from an ORM, I would simply add Transfer to that list. :)
Hope that clarifies.
I've worked with both Transfer and Reactor, and a *majority* of time, couldn't imagine working without one of the two. Although, while they are really nice for abstracting SQL, I will say that it is a *must* that every developer know and get comfortable with SQL, for when a custom query or two is necessary.