Context Docs: Creating a Context Declaratively
It's time to cover the second method of configuring and initializing an instance of Context - the declarative approach.
It's important to note that everything we're about to cover can also be done with the programmatic method, however using the declarative approach may feel a bit easier.
The cfcommons Context leverages the ever-popular XML approach as a declarative mechanism to configuring a Conext. Below is a sample XML configuration file that one could use to configure a Context instance;
There are two nodes that introduce the concept of environment-specific configuration for a Context; <environment-mappings /> and <configurations />. The <configurations /> tag can contain any number of <config /> nodes. The <config /> node is a context configuration and specifies the the name of the context (which is used only for the environment-mappings), it's root - as we discussed previously with the programmatic approach, and each plugin that will be provided to the context. The <environment-mappings /> node creates a named environment consisting of a corresponding config. The value of the "config" attribute of the <env /> tag must correspond directly to a <config /> "name" attribute or an exception will be thrown.
The <plugin /> node specifies the class of the specific plugin to be injected into the context AND any number of initialization parameters for that specific Plugin. Each parameter is mapped to a constructor argument on the plugin itself. If a plugin constructor argument requires something more complicated than a simple value, then you'll likely have to specify a configuration file location for that plugin - but that's entirely dictated by the plugin itself.
Using the autowiring example from the previous tutorial, we'll construct an XML configuration for the same exact setup to demonstrate the declarative approach;
In this example, we're not really leveraging the flexibility of different environment configurations - we simply want to recreate a declarative example of the previous tutorial. Now in order to create the instance of context like we did before, we need to ask for the context from a factory - instead of instantiating the context directly;
The PluggableContextFactory will take the configuration file location AND a valid environment value and construct a Context instance based off of the declarative configuration provided in the file. The reload node and value is only relevant for HTTPContexts.
Notice how unlike the programmatic approach, we don't invoke the finalize() method on the resulting context - this is done for us by the factory. We now have a ready-to-use context and just like our programmatically-constructed instance, we can invoke the getObjectInstance() method on the resulting context and expect a fully dependency-injected object instance in return because of the registered NeodymiumPlugin.