Hi Brett,
]
There are many ways to achieve this, but let’s cover the simplest and best ways.
To familiarize yourself with ColdBox, you may want to run through our getting started guide:
http://coldbox.ortusbooks.com/content/getting_started_guide/index.html
And here’s a quick reference card for WireBox:
https://github.com/ColdBox/cbox-refcards/raw/master/WireBox/WireBox-Refcard.pdf
By default, ColdBox (WireBox inside of ColdBox, that is) looks for models in a folder called “models”.
So if I have /models/foo.cfc I can ask WireBox for “foo”. If I have /models/folder1/folder2/foo.cfc then I can ask for “folder1.folder2.foo”. The models folder is called the default scan location.
If your CFC names are unique and you don’t want to specify the full component path, you can place the following line in your /config/WireBox.cfc’s configure() method:
mapDirectory( “models” )
This will scan the folder on start and map every model by the name of the CFC. Use an alias annotation in the CFC to add additional names to the CFCs.
So, on to your question about providing constructor injection. If the LoginBeanFactory and AgencyBeanFactory are already mapped in WireBox by that name, your code should actually work as is. The longhand way is to add an **"**inject" annotation to the argument like so, but required constructor param default to being injected and the mapping name defaults to the argument name:
or
I personally avoid constructor args because they’re annoying and add boilerplate to my code. A cleaner way is to use mixins by just adding properties to the top of your CFC like so:
component {
property name=“foo” inject=“foo”;
property name=“myBar” inject=“bar”;
function onDIComplete() {
foo.doSomething();
myBar.doSomething();
}
}
That will automatically create variables.foo and variables.myBar in your CFC on creation.
Now, I did notice that the two CFCs in your example are factories. That’s a very Java-esque thing to have, but when using ColdBox, WireBox IS your factory. Can you explain what your factories do? There might be a better way to handle them using WireBox’s many built-in features.
Now, to address your last bit-- you seemed to imply that you’ve gone to the trouble of breaking your site up into logical chunks or libraries. This sounds like it might be a great use for ColdBox modules. A module is a chunk of your application that can either stand alone, or just be separate for organizational reasons. Each module lives in a folder inside the /modules directory and has a simple ModuleConfig.cfc inside that describes it. WireBox is module-aware and modules have their own “models” convention.
So consider these two simple modules, that both have some CFCs inside:
/modules/security/models/user.cfc
/modules/security/models/userService.cfc
/modules/orders/models/Customer.cfc
/modules/orders/models/CustomerService.cfc
With zero configuration, we can ask WireBox for these like so:
getinstance( “UserService@security” )
getinstance( “CustomerService@orders” )
Or, we can inject the same CFCs like so:
component {
property name=“UserService” inject=“UserService@security”;
property name=“CustomerService” inject=“CustomerService@orders”;
}
Or, if you really want, you can get them in your constructor like so (script syntax):
component {
/**
-
@UserService.inject UserService@security
-
@CustomerService.inject CustomerService@orders
*/
function init( UserService, CustomerService ) {
…
}
}
This is just the tip of what modules can do for you. Hopefully this isn’t too much information for you. Digest it and come back with more questions. Also note, I’m on the CFML Slack chat if you want to pop in and question some questions in the #box-products channel.
http://cfml-slack.herokuapp.com/
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
