Warning! This page has the following tags:

  • This page is not necessarily deprecated, but may need to be updated.
  • This page needs to be merged with docbook documentation.

Environments And Contexts

Introduction

The behavior of an application is controlled mainly by two things: the Environment and the Context. Both have an influence on settings, what implementations are used for Controller, User etc and much more.

Environments

Environments define in which environment (e.g. development, testing, production) the application runs. Parts of the application configuration can be environment-specific, for instance, the debug mode, the database configuration etc.

Contexts

Contexts are executed inside Environments, but they are not specific to any of the defined Environments (i.e. all contexts exist in each environment). Each Context has influence on the execution flow of the application mainly by defining factories that control the execution. Possible contexts would be "web", "console" or "xmlrpc".

Overlapping Parts

While many configurational aspects of environments and contexts can be separated in a clean way (e.g. the SecurityFilter?, DatabaseManager?, ActionStack? and LoggerManager?, the config handlers, compile configuration and database config are defined by the Environment), some things fit into both areas:

  • Filter configuration. You want the ExecutionTimeFilter? only in development and testing Environments, but you don't want it for console or xmlrpc Contexts
  • Controller and Request. While these usually only matter to the Context (ConsoleRequest?, FrontWebController? etc), you might want to use Request and Controller implementations which emulate cookies or request URLs or whatever in a testing Environment
  • Autoload configuration. Not sure about this one, but there might be situations where you need to configure these per Context. Since this might be a little difficult to implement, we'd likely make this one Env-only in case of doubt.
  • ExecutionFilter?. Obviously, you want a CachingExecutionFilter? in production mode, but the "vanilla" version for development. It's quite unlikely, but _maybe_ special circumstances could force you to want this be configurable per Context, too.
  • ValidatorManager?? The entire validaton thing is pretty web-centric.
  • User and Storage implementations? Have to think about this. Testing with emulation of things comes to mind here, again. But you probably need different authentication methods per Context (protected RSS feed with credentials in the URL, Website needs login first, SOAP requests have the auth info in the message body)

:S