The following chart shows you the most common methods when dealing with the WireBox Injector. This doesn't mean there are no other methods on the Injector that are of value, so please check out the CFC Docs for more in-depth knowledge.

Now that we have constructed our injector let's discuss a little about injection idioms or styles WireBox offers before we go all cowboy and start configuring and using this puppy. The styles shown below are written in execution order.

Constructor (1)

Motivation: Mandatory dependencies for object creation

Each constructor argument receives a inject annotation with its required injection DSL. Be careful when dealing with object circular dependencies as they will fail via constructor injection due to its chicken and the egg nature

Object Properties (2)

Motivation: Great documentable approach to variable mixins to reduce getter/setter verbosity

Leverages the greatest aspect of ColdFusion, the dynamic language, to mixin variables at runtime by using the cfproperty annotations. Great for documentation and visualizing object dependencies and safe for circular dependencies.

Cons is that you can not use the dependencies in an object's constructor method-- instead use onDIComplete().

Setter Methods (3)

Motivation: Legacy classes

The inject annotation MUST exist on the setter method if the object is not mapped. Mapping must be done if you do not have access to the source or you do not want to touch the source.

Cons is that you can not use the dependencies in an object's constructor method-- instead use onDIComplete().

Summary

These are the three injection styles that WireBox supports and which style you choose depends on your requirements and also your personal taste. The setter method approach is linked to the way Spring and ColdSpring approach it which is the traditional JavaBean style of setXXX where XXX is the name of the mapping or object to pass into the setter method for injection.

WireBox bases itself on the idea of creating object injectors (wirebox.system.ioc.Injector) that in turn will produce and wire all your objects. You can create as many injector instances as you like in your applications, each with configurable differences or be linked hierarchically by setting each other as parent injectors.

Each injector can be configured with a configuration binder or none at all. If you are a purely annotations based kind of developer and don't mind requesting pathed components by convention, then you can use the no-configuration approach and not even have a single configuration file, all using autowiring and discovery of conventions. However, if you would like to alter the behavior of the injector and also create object mappings, you will need a configuration binder. The next section explains the way to create this configuration binder, below is how to startup or bootstrap the injector in different manners:

No Configuration Binder:

myObject = new coldbox.system.ioc.Injector().getInstance("my.object");

With a Configuration Binder:

myObject = new coldbox.system.ioc.Injector("myBinderPath").getInstance("CoolObject");

The WireBox injector class is the pivotal class that orchestrates DI, instance events and so much more. We really encourage you to study its API Docs to learn more about its construction and usage methods.

The injector can be constructed with three optional arguments:

If you are using WireBox within a ColdBox application, you don't even need to do any of this, we do it for you by using some configuration data in your ColdBox configuration file or conventions.

// Simple Creation - automatically stored in application.wirebox
new coldbox.system.ioc.Injector()

// Custom Binder
new coldbox.system.ioc.Injector( "config.MyBinder" )

// Custome Binder + Properties
new coldbox.system.ioc.Injector( "config.MyBinder", { props } )