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:
With a Configuration Binder:
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.
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. Below is a nice chart that showcases the WireBox injection styles, but we really encourage you to review our dependency injection section to learn the different approaches to DI, their values, and when to use them.
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.
Note Whichever injection style you use with WireBox, the target's visibility does not matter. This means that you can create private or package methods and WireBox will still inject them for you. This is absolutely great when you are an encapsulation freak and you do not want to expose public setter methods.
Argument | Type | Required | Default | Description |
binder | instance or instatiation path | false |
| The binder instance or instantiation path to be used to configure this WireBox injector with |
properties | struct | false | structnew() | A structure of name value pairs usually used for configuration data that will be passed to the binder for usage in configuration. |
coldbox |
| false | null | A reference to the ColdBox application context you will be linking the Injector to. |
Style | Order | Motivation | Comments |
Constructor | First | 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 |
CFProperty | Second | Great documentable approach to variable mixins to reduce getter/setter verbosity | Leverages the greatest aspect of ColdFusion, 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 |
Setter Methods | Third | 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. |