ColdBox 4.0.0 beta

Congratulations on the beta release! I’m loving the increased emphasis on modules.

I see that modules have a new property autoMapModels which defaults to TRUE.

Question 1: If this is set to FALSE instead, does that mean that a modules models will now be private from the application and any other models?

Question 2: If question 1 is true, is there an WireBox injector just for the module that can autowire these private models into module handlers, etc?

I would very much like to create a module that exports only a single model (or a few models) to the Application WireBox, but can still autowire all of the modules private models within the module. I had thought to do this with a hierarchical injector, but in ColdBox 3.x components within the module are autowired with the Application Wirebox as retrieved from the Controller. I could have used the ControllerDecorator, to track a WireBox injector for each module, but that was more modifications to the core framework than I wanted to do.

Is this achievable in 4.0.0 out of the box (pun intended)? If not, would you consider a pull request that enabled this?

Seth Feldkamp

> I see that modules have a new property autoMapModels which defaults to TRUE.
> Question 1: If this is set to FALSE instead, does that mean that a modules models will now be private from the application and any other models?

False is simply the fallback behavior to how modules always behaved in ColdBox 3.x. Basically when you activate the module, it’s model convention folder is added to the parent WireBox injector as a scan location but no CFCs are explicitly mapped unless you do some yourself in the ModuleConfig.cfc. I don’t know that I’d say the modules models are private since they are accessible via the scan location, but they aren’t “advertised” and they won’t override any existing mappings.

To fully explain what the autoMapModels flag does-- when set to true (the default in ColdBox 4), all of the models for that modules are automatically mapped when the module is loaded in their own “namespace” as controlled by the modelNamespace property (the module namespace defaults to the module name) . So if a module is called “foo” and has a model called “user.cfc”, a mapping will be created automatically called “user@foo” that is available to the rest of the application. This is the pattern Luis did manually at first with ContentBox, but now will be part of the core to reduce a ton of boilerplate code in ModuleConfig.cfc.

Question 2: If question 1 is true, is there an WireBox injector just for the module that can autowire these private models into module handlers, etc?

No. not yet but that is similar to our plan. A later version of the beta will have this functionality and it will go hand-in-hand with module inception (nested modules) for multi-version dependencies like Node allows. (Where two modules in an application both need different versions of a third module). The dedicated injector won’t be so much to keep a module’s models private but instead to allow it to sandbox its nested modules so no one else sees them.

Perhaps a convention to allow a module to separate its internal bits from its public API can be something we consider if it has value to others but we would have to figure out what that would look like.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

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

Thank you for the explanation.

I would be very interested in a convention for what a module exposes as it’s public API. If anyone else feels the same, please reply.