ColdBox <3 Legacy AppWRAP YOUR APP WITH IMPLICIT VIEW DISPATCH
Your Host #1‣ Scott Coldwell
‣ Developer at Computer Know How
‣ Houston, TX
‣ CF dev since 2006
‣ @scottcoldwell
Your Host #2‣ Brad Wood
‣ Developer at Ortus Solutions
‣ Kansas City, MO
‣ twitter: @bdw429s
ColdBox seems great! But…😔
There’s HOPE!
‣ Define Implicit View Dispatch
‣ Practical steps to port your legacy app
‣ A vision for moving forward after porting
‣ Demo using CommandBox
What We’ll Learn
Implicating a dispatched view…huh?‣ In ColdBox, if a view file exists, it can be called
without a handler
‣ The handler/event are implicitly created
‣ The view doesn’t need to know anything about ColdBox
‣ You could write an entire app with only views
‣ If you could write an entire app with only views, you can drop an existing application into the views directory, and it would run*!
‣ * slight modifications may be necessary‡
‣ ‡ … are almost definitely necessary
‣ Good news: fairly straightforward
Drop in that legacy app!
‣ Make URLs compatible (index.cfm)
‣ Deal with Application.cfc/cfm
‣ Routes
‣ cfincludes, createObject, etc
Overview of Must-Dos
‣ Primary concern: index.cfm in ColdBox URLs
‣ ColdBox has URLs like this out of the box: ‣ http://myapp.com/index.cfm/user/account
‣ But your app probably had a URL such as: ‣ http://myapp.com/user/account.cfm
‣ NOTE: the .cfm extension is no longer necessary, but IS permitted
‣ To fix: Enable SES URL setting in CB; web server rewrite rules (see docs)
Must Do: URL Compatibility
‣ Coldbox is now the Application.
‣ Settings, environment variables, and other magic must find a new home ‣ May I recommend ColdBox settings and environments?
‣ Datasources, mappings, etc can be moved to ColdBox’s Application.cfc
Must Do: Application.cfm/cfc
‣ ColdBox auto-generates (implicitly dispatches) handlers and routes for most cases
‣ You need custom routes for 2+ deep directories ‣ addRoute(pattern="/ajax/tags/:action", handler="ajax/tags");
‣ Use CLI tools to get a list for you ‣ find with mindepth option
Must Do: Routes
‣ Prepend all <cfinclude> template values with /?views/
‣ - <cfinclude template=“/widgets/top_nav.cfm”>
‣ + <cfinclude template=“/views/widgets/top_nav.cfm”>
‣ - myObj = createObject(“component”,”cfc.myCoolObject”);
‣ + myObj = createObject(“component”,”views.cfc.myCoolObject”);
Must Dos: cfincludes, createObject, etc
‣ CFC invocation: createobject ()-> getModel() ‣ WireBox
‣ Move settings and environmental settings to ColdBox.cfc
‣ Utilize Layouts ‣ Assign layouts to views in ColdBox.cfc ‣ empty layout
Overview of Should-Dos
‣ Use getModel() instead of CreateObject() ‣ easy search/replace
‣ Use WireBox inside of model objects ‣ + <cfproperty name="myOldCFC" inject=“model:myOldCFC">
‣ - <cfset foobar = createObject("component","myOldCFC").doSomethingAwesome() />
‣ + <cfset foobar = myOldCFC.doSomethingAwesome() />
‣ Consider how to handle the init() call, if applicable
Should Do: CFC invocation
‣ ColdBox has great settings management
‣ ColdBox has great environment management
‣ Use them
‣ Search/replace ‣ - application.mySpecialSetting
‣ + getSetting("mySpecialSetting")
Should Do: Settings, environments
Should Do: Layouts‣ See if it makes sense for your app
‣ Control multiple layouts via Coldbox.cfc
‣ Special cases
‣ Blank layout for ajax responses
‣ Move static assets to /includes
‣ Move CFCs to /models
‣ Utilize Security interceptor
‣ Configure WireBox for models
‣ Use RC scope instead of form/url
Overview of Could-Dos
‣ New development can be ColdBoxy
‣ Refactor legacy code to be MVC using models, handlers, and views
‣ Tighter integration with ColdBox offerings: (e.g. LogBox, ForgeBox items,
etc)
Going forward
‣ Lay as much groundwork as you can, but get it out the door
‣ Search and replace (with regex) is your friend!
‣ Use a build process, not just source control
‣ Don’t take on too much at once! Port the app, then refactor
Final Notes
ColdBox all the things