[coldbox-4.0.0-be] Alternative structure example

Does anyone have a configuration file for Coldbox that uses a directory structure where the all framework files, handlers, views, etc are above the publicly accessible webroot. Something like:

project_root
…coldbox
…handlers
…etc
…webroot
…Application.cfc
…index.cfm

I’ve been spending some time with CommandBox the last couple of nights and love how easy it is to use it to install things from ForgeBox. I was able to get a new site up and running with the default application directory structure, but it goes against what is traditionally recommended to dump all this stuff willy-nilly into the web root.

I’ve created mappings for config, coldbox, handlers, model, layouts, etc in my Application.cfc and have gotten the framework loaded. Then I found out about the conventions setting in config/Coldbox.cfc and have set mine up like so:

conventions = {
handlersLocation = “/handlers”,
pluginsLocation = “/plugins”,
viewsLocation = “/views”,
layoutsLocation = “/layouts”,
modelsLocation = “/model”,
eventAction = “index”
};

However, I’m running into an error that says “Main.onAppInit is not valid registered event.” when it clearly is in the /handlers/Main.cfc file.

I searched the group archives and about the only thing I could find was a thread started by Mark Mandel in 2010 but there didn’t seem to be a resolution for it.

How difficult would it be to create a new skeleton with everything configured correctly for this type of organization (AdvancedScriptAlternate or some such)? I’ve been trying different things for the last couple of hours and can’t seem to hit the magic combination to make things work.

Thanks for your time.
Dan

Make sure the conventions outside of the webroot, have ColdFusion or IIS / Apache mappings.

The convention setting is not what you want. That lets you rename the folders in the web root. What you want is to use the “external” settings.

http://wiki.coldbox.org/wiki/ConfigurationCFC.cfm#Extension_Points_Settings

So, for instance, you can have a folder on handlers anywhere on your hard drive like so. This example assumes you have created a mapping called “/handlers”:

handlersExternalLocation = “handlers”,

Note, the setting is a dot-notation path, so you will need to have a mapping that points to it.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Dan, I took the “advanced script” sample app and and reorganized it into a working example of what you want to do.

https://github.com/bdw429s/ColdBox-External-Sample-App

Libs is where I put ColdBox
appRoot is where most everything lives
and webRoot is the web accessible stuff.

I switched into the webroot folder in CommandBox and ran the “start” command to fire up the server there. There are tweaks to Application.cfc, as well as ColdBox.cfc, and WireBox.cfc to repoint everything. Hopefully this working example helps to show you want to do.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Would it not be quicker to write this

Thanks Brad…I’ll take a look at that today but it sounds like exactly what I wanted to accomplish.

One question though, by putting all the ColdBox related stuff inside libs, is that going to mess with CommandBox’s ability to install new things from ForgeBox? Or do you just cd into libs before running the Forgebox install command?

Disregard that question…was easy enough to test the theory and find out that forgebox install just works on whatever directory you’re in.

Thanks again!
Dan

Funny you say that, I started out with that line of code, but then I was thinking every time I do that I find out it only works on Railo, or Windows, etc. It was 3 am and I didn’t have an easy way to test it on other operating systems and I didn’t feel like testing it on Adobe CF so I just went with something I knew would work.

If that does work on all systems and engines, I can update the example because it is my preferred approach.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

The “forgebox install” command in CommandBox will work like so when installing

  1. If the package being installed has a box.json in the root of the zip, it’s “directory” directive will be used as the install location relative to the current working dir. i.e. “/modules”
  2. If no box.json is found in the incoming package, the current working directory will be used
  3. If a directory parameter is passed to the install command, it will override everything
    So for libraries that you need to be able to create via CFC mappings, if you stick it in the web root, it will just work. If you rearrange your structure and put it somewhere else, it’s up to you to create a CF mapping that points to where ever you installed it.

Now, on that note— in ColdBox 4, modules can actually register ColdFusion mappings with the engine when they are loaded. This is a very exciting feature and Adobe even added support for this into CF11 just for us (there was a hack-around in previous versions). What this means if if you have a module called “foobar” and it registers a CF mapping of the same name-- you can put your modules directory ANYWHERE on your hard drive and when you drop in your “foobar” module, you’ll immediately be able to access “foobar.model.fooService” etc via the root mapping. That also means the foobar module can use interfaces and inheritance inside of itself because it will be fully self-contained.

On top of that, ColdBox 4 will automatically map foobar’s models in WireBox so you can do getModel( “foobar@fooService” ) to load its bits.

That’s why we’re really pushing modules. We doing a lot of work to make them awesome for stand-alone package of code (simple or complex) that can be dropped in anywhere and easily pulled into the app regardless of where they are stored. This gives way more flexibility on how you want to arrange your app while still having an easy-install option for packages that “just works”. Also, ColdBox can have multiple module locations.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Not sure what you where doing, that is standard OS stuff.

Brad,

Can you elaborate a bit on the hack-around to register CF mappings from Coldbox prior to CF11 ?

Thanks,

Cristian

Here is how to add an app mapping on each engine/version:

Railo (supported):

// Railo caches app mappings, but gives us a method to update them via the application “tag”
function addMapping( name, path ) {
var mappings = getApplicationSettings().mappings;
mappings[ name ] = path;
application action=‘update’ mappings=’#mappings#’;
}

CF11 (supported):

// No workaround neccessary for CF11 and up
function addMappingCF( name, path) {
var appSettings = getApplicationMetadata();
appSettings.mappings[ name ] = path;
}

CF10 (unsupported):

// For CF10, Add the mappings into the the application settings map
// This is because getApplicationMetadata().mappings is null if none exist
function addMappingCF10( name, path) {
var appSettings = application.getApplicationSettingsMap();
appSettings.mappings[ name ] = path;
}

CF9 (unsupported)

// CF9 is same as CF10, but with Slightly different method name
function addMappingCF9( name, path) {
var appSettings = application.getApplicationSettings();
appSettings.mappings[ name ] = path;
}

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

I wish ORM was that easy.