Into The Box Notes: Converting Legacy Apps into Modern MVC - Brad Wood, Scott Coldwell

Can’t convert a legacy app into structured MVC overnight

Implicit View Dispatch in ColdBox
can just have a CFM file in a view. can have ANY CFML you want in it (queries, whatever)
can drop that in the Views folder, if i hit it with the right URL it will work
don’t get any greatness from ColdBox that way, but it will at least ‘work’ as a base starting point

with IVD - the handler / event are “implicitly created”
the view doesn’t need to know netting about ColdBox
you COULD write an entire app only with views
if you can WRITE an app entirely in the /views folder, then you could drop an entire legacy app in the /views folder and it will (mostly) run
some modifications are necessary -
make URLs compatible (index.cfm formatting)
- not a huge deal, but you have to take care of it
Application.cfm/cfc -
ColdBox IS the app, so you can’t expect the ColdBox App.cfc to do whatever your legacy one did. need to factor that in.

URL compatibility
primary concern - index.cfm in ColdBux urls
CB URLs look like so: http://site/index.cfm/user/account
legacy app uses URLs in the “legacy” way — http://myapp.com/user/account.cfm
can handle this with rewrite rules in apache/ngnix, etc
the .cfm extension is permitted but isn’t “necessary”, which can help with this process
to fix: enable SES URL settings in CB; web server rewrite rules

Application.cfc/cfm
settings, env variables, other magic that needs a new home
- ColdBox settings / environments work well for this

Routes -
CB 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 (“find” is a Bash tool)

cfincludes, createObject, etc
prepend all cfinclude templates with /?views/

doing just those things will get you pretty far down the line, but still won’t be getting any of the ColdBox magic

WireBox - to call your CFCs:
createObject()->getModel()

move settings and env vars to ColdBox.cfc

Utilize Layouts
Assign layouts to views in ColdBox.cfc
- empty layout

use getModel() via WireBox instead of CreateObject()

CB has good settings / env management
search/replace application.mySettings —> getSetting()
mostly works just as-as, depends on your app

“nice to do” items, but not required —

move static assets to /includes

move CFCs to /models

security for app — use Security Interceptor

Configure WireBox for models

goal: to change as FEW things as possible to get the app to “run” and do some broad sweeping things to gain control of the app via ColdBox

Use RC scope instead of form/url

Going forward -
app is pretty much running in CB now
new / future dev can be ColdBox based
now have freedom to refactor over time as we go. don’t need to tell the boss “i need 6 months just to make this a ColdBox app”

Refactor legacy cold tho be MVC using models, handlers, views

Lay as much groundwork as you CAN, but get it out the door!
can continue doing things down the road
don’t try to make it perfect at first

search/replace (regex is your friend)

Use a build process, not just source control
doing this JUST in source control is complex because you’re moving files around
if another dev is fixing bugs at the same time, this can get really crazy
might be better done via an Ant script or something, especially true on larger teams, more than 1 developer

don’t take on too much at once, port the app, THEN refactor