Context Docs: Introduction
A Context itself is a very basic and almost behaviorless object. It's sole purpose is to "understand" each and every component (CFC) within it's root. It leverages the org.cfcommons.reflection module library in order to create this understanding of it's contents. The Context provides a flexible Plugin architecture and associated API. It is through the Plugin architecture that a Context recieves it's intended behavior and extended API.
That was a mouthful, and a bit abstract. Imagine a Context as a container. You tell that container to "care" about a set of CFC's (root). You then place Plugins inside of the container. Anything can now interact with that container in the manner prescribed by the Plugins. The Plugins inherently know about the content's of the container - both CFC's and other Plugins and can interact with any other element within the container to produce behavior as well.
Figure 1.1 is a simplified view of the Context platform general architecture. It's primary function is to provide an infrastructure upon which both web (HTTP) and non-web functionality rests, creating an application platform. The behavior and extensibility of the infrastructure is limited only by the behavior of available plugins;
Figure 1.1
HTTP vs. Pluggable Context
As you can also see from the above diagram, a Context comes in two different flavors; a "vanilla" Context and an HTTPContext. Both are interfaces with associated concrete implementations PluggableContext and HTTPContext respectively. HTTPContext extends PluggableContext, and as such exposes all of the methods and behaviors of a PluggableContext with one exception - it also provides a respond() method. It is the intent of the HTTPContext to act like a container purposed as a web application. HTTPPlugins correspond to an HTTPContext in that the HTTPPlugin interface exposes a getResponse() method. This gives those types of plugins an opportunity to create or agument a response intended for a web client when the parent context's respond() method is invoked - we'll get into these details later on as well. Although the diagram indicates that HTTPPlugin types are only associated to an HTTPContext, this is not technically true - you can add an HTTPPlugin to a context that is not of type HTTPContext, but that context will ignore the getResponse() method of that plugin.