Into The Box Notes: Integrating MVC Into Legacy - Brad Wood

April 29, 2018

the state of your app
what does it currently look like?
is it partially converted to ColdBox?
what are your goals?
are you looking for new features?
better support on a newer version of CF?

reasons to migrate to a modern framework
code organization
a known location for everything
rather than blindly searching folders on a new (to you) codebase

makes your dev shop more attractive to prospective employees

Is your dev shop a place people WANT to go work?
Are you using source control, unit testing, MVC, etc?

Nobody wants to be drafted by a losing team.

A framework isn’t a silver bullet
you still have to write code
but the overall goal is ITERATIVE improvement
don’t do a full rewrite at 1 time
that will fail

baby steps are better than trying everything new at once
write something first that you PLAN to throw away
now you know where you want to go, but your first rev will be terrible, so learn the concept, learn the pitfalls, then throw that code out and do it better.

don’t spend weeks fretting over how to do it
just pick something, try it, and if you hate it, throw it out

/coldbox needs to be at webroot (or you have a mapping that points there)

ColdBox CAN co-exist with legacy code

it’s also possible to find/replace legacy code to use ColdBox settings

can use legacy checks for the environment

don’t HAVE to convert everything to coldbox settings
can still use Application.variableName if you need to as a bridge during the rewrite

Application.cfm to CFC

watch out for the transcendent variables scope
use onRequest() if needed

variables.mySetting = “value
include argumetns.targetPage

Add in ColdBox bootstrap
ColdBox is always loaded

play w/ ColdBox in a complete vacuum
ColdBox create app
makes a folder and puts the stuff in there

creates some ColdBox stuff

loads some ColdBox things

you probably have stuff in your current app.cfc
pull up the ColdBox one and merge in the pieces you want

2 ways to bootstrap ColdBox
1. inheritance approach
in application.cfc - extends coldbox.system.Bootstrap

can’t use app specific mappings tho

2. instead of “extends” approach
manually create the bits in on applicationstart() and onrequeststart(), on sessionstart(), etc.

bare min to get ColdBox loaded:

everything else is optional (the events just won’t fire if you don’t have the corresponding code)

you get to decide what requests to go ColdBox and what requests don’t!
return value of that function is important
true - will continue processing
false - coldfusion stops, finishes the request right then

if you it site/products.cfm
retunrn false, it never reaches the products.cfm

key piece of controlling which requests go thru to ColdBox and which don’t

if( cgi.something == “somehting coldbox related” )
app.cbootstrap.onrequststart( args.targetpage ) // run your ColdBox stuff
return false;
return true; // run your legacy stuff

start w/ main layout of your site
so you have a backdrop
header/footer files
pick the most common header file for your app and start w/ converting that

in layout
only line required is renderView()
output of that will be the html view you set in your handler
everything before/after is your layout header/footer

this will let you start converting views

often you’ll have both the legacy and ColdBox versions of your site side by side for a while

don’t want to have 2 copies of that code
so if you can abstract that code into a cfinclude
and include those in your coldbox side, you can reuse that code in both legacy and coldbox

Start plugging in ColdBox aspects
proactively convert legacy:
logging - logBox
caching - cache box
cfc creatio - wirebox
these can ALL work outside of ColdBox! use them in you legacy app!

Pick a site area to start
the goal is to get 1 success into Production
then tell the project owner about the success and progress

maybe something else, like a login page
move .cfm pages into a view
implicit view dispatch
swap out build link calls

can create an empty view
copy/paste all the code from legacyLogin.cfm into the view
and it will be IN ColdBox

few things to change
swap out how you build links
href=“#event.buildLink( ‘event.thing’ )#”

handle external urls -
can also put custom routing in app.cfc
put in URL rewrites at the web server level

shortening your feedback loop
don’t spend a LONG time trying to get something out the door
when you have part of the app working, test it and release it!
don’t try to save up and do a huge chunk, you’ll never finish!

use code reviews to get quick feedback from your internal team meetings if possible.

make sure you update your product owner so the know about your progress

repo with half legacy CF and half Coldbox
to show it all running together in 1 place.

compare features
show they’re not different
package manager
memer functions

[ code demo ]

can get started w/ an empty handler
and put all YOUR legacy.cfm stuff in the view to start
then refactor later slowly to get the data out of prc and into the handler, etc.

coldbox create module brad
coldbox reinit
brad = module
home = handler
(and there is a default action inside it)
url ?fwreinit=1