This class supports a singleton object that contains your server configuration plus pointers to other OpenInteract services. Much of the information it holds is similar to what was in the OpenInteract::Request ($R) object in OpenInteract 1.x. However, the OpenInteract2::Context object does not include any information about the current request.

The context contains the action table and can lookup action information as well as create a OpenInteract2::Action object from it. (See lookup_action(), lookup_action_info(), lookup_action_none(), lookup_action_not_found())

This is the method you will see many times when the object is not being imported, since it returns the current context. There is only one context object available at any one time. If the context has not yet been created (with create()) then we either throw an exception if $no_exception is false or return undef if $no_exception is true. (Subclasses of OpenInteract2::Exception should set $no_exception to avoid an infinite loop...)

Creates a new context. If you pass in a OpenInteract2::Config::Base object or specify 'website_dir' in \%setup_params, it will run the server initialization routines in setup(). (If you pass in an invalid directory for the parameter an exception is thrown.)

If you do not know these items when the context is created, you can do something like:

You may also initialize the Log::Log4perl logger when creating the context by passing a true value for the 'initialize_log' parameter in \%setup_params. This is typically only done for standalone scripts and as a convenience. For example:

If you pass to create() a base_config object or a valid website directory, setup() will be called automatically.

You can skip steps of the process by passing the step name in an arrayref 'skip' in \%params. (You normally pass these to create().) This is most useful when you are creating a website for the first time.

For instance, if you do not wish to activate the SPOPS objects:

OpenInteract2::Context->create({ skip => 'activate spops' });

If you do not wish to read in the action table or SPOPS configuration:

Read in the action table from the available packages. (Setup: read_action_table()) We also ensure that all classes referenced in the action table are brought into the system via require. (Skip: 'initialize action')

Read in the SPOPS object configurations from the available packages. (Setup: read_spops_config()) Activate all SPOPS objects at once. (Setup: activate_spops_classes()) (Skip: 'initialize spops'; you can also skip just the activation step with 'activate spops')

Read in the localized messages from all packages. (Setup: read_localized_messages()). (Skip: 'initialize messages')

Create the cache. If it is not configured this is a no-op. (Setup: create_cache()) (Skip: 'initialize cache')

A factory for creating DateTime objects using the timezone() from the context. Any parameters in \%params will be passed along to the DateTime constructor (with one exception, see below) but if you do not specify a year then we assume you want the current time and call the DateTimenow() method.

The exception: when you specify 'epoch' in \%params we call the from_epoch() method instead of the constructor.

This is just a shortcut method and you instead may want to get the timezone from the context to create your own DateTime objects. Up to you.

Looks up the information for $action_name in the action table and returns a OpenInteract2::Action object created from it. We also pass along \%values as the second argument to new() -- any properties found there will override what is in the action table configuration, and any properties there will be set into the resulting object.

Given the URL piece $url_chunk, find the associated action name. Whenever we set the action table (using action_table()), we scan the actions to see if they have an associated URL, peeking into the 'url' key in the action configuration.

If so, we only create one entry in the URL-to-name mapping.

If not, we create three entries in the URL-to-name mapping: the lowercased name, the uppercased name, and the name with the first character uppercased.

Additionally, we check the action configuration key 'url_alt' to see if it may have one or more URLs that it responds to. Each of these go into the URL-to-name mapping as well.

For example, say we had the following action configuration:

[news]
class = OpenInteract2::Action::News
task_default = list

This would give the action key 'news' to three separate URLs: 'news', 'NEWS', and 'News'.

Finds the action configured for when an action is not found. This can be used when an action is requested but not found in the action table. Think of it as a 'catch-all' for requests you cannot foresee in advance, such as mapping requests to the filesystem to an OpenInteract action.

Currently, this is not called by default when you try to lookup an action that is not found. This is a change from 1.x behavior. Instead, you would probably do something like:

Returns a hashref of information about $controller_name. If $controller_name not given returns a hashref with the controller names as keys and the associated info as values. This is typically just a class and content generator type, but we may add more...

Returns the data (a hashref) associated with $generator_name. If you want the object associated with $generator_name use content_generator(), below. If you do not provide $generator_name returns a hashref of all content generator information, keys as the generator names and values as the data associated with them.

content_generator( $name )

Returns information necessary to call the content generator named by $name. A 'content generator' is simply a class which can marry some sort of template with some sort of data to produce content. The generator that is used most prominently in OpenInteract is built around the Template Toolkit, but it also includes implementations for other templating systems (HTML::Template and Text::Template), and there is no reason you cannot use an entirely different technology, like SOAP.

Returns: an object with a parent of OpenInteract2::ContentGenerator. Generally you would only call generate() on it with the appropriate parameters to get the generated content -- these are initialized in setup().

Returns the data (a hashref) associated with $indexer_name. If you want the object associated with $indexer_name use fulltext_indexer(), below. If you do not provide $indexer_name returns a hashref of all fulltext indexer information, keys as the indexer names and values as the data associated with them. There is also the additional key 'default' which holds the name of the default fulltext indexer.

fulltext_indexer( [ $indexer_name ] )

Return the OpenInteract2::FullTextSearch object associated with $indexer_name. If $indexer_name not provided it uses the value of the server configuration key 'fulltext.default'.

There are three separate deployment contexts used in OpenInteract2: the application context, image context and static context. These control how OI2 parses incoming requests and the URLs it generates in OpenInteract2::URL.

All deployment contexts are set from the server configuration file at startup. You'll find the relevant configuration keys under context_info.

assign_deploy_url( $path )

This is the primary application context, and the one you should be most interested in. OI2 uses this value to define a URL-space which it controls. Since OI2 controls the space it's free to parse incoming URLs and assign resources to them, and to generate URLs and have them map to known resources.

The default deployment context is '', or the root context. So the following request:

will not be properly parsed by OI2. In fact OI2 won't be able to find an action for the request and will map it to the 'none' action, which is not what you want. Instead it will look for the following:

The server configuration key system_class holds a number of name-to-class mappings for some system resources. This is a way to lookup a class based on the name. For example, if you want to manipulate the page template objects you'd use:

NOTE: This replaces the aliasing feature found in early betas of OI2 and in all versions of OI 1.x. The aliasing feature would create methods for each name found in the server configuration key server_alias so you'd previously have:

This is preferred to poking about in the server configuration data structure yourself.

Returns: fully-qualified directory

lookup_temp_lib_directory()

Creates the fully-qualified name for the temporary library directory. This can be specified in the base configuration (conf/base.conf) or a default (tmplib/) is provided. Both are relative to the website directory.

This method does not care of the directory exists or not, it just creates the name.

Returns: fully-qualified directory

lookup_temp_lib_refresh_filename()

Relative name of file in the temporary library directory that is used (by OpenInteract2::Setup) to identify whether the directory needs refreshed. Normally this is 'refresh.txt'.

Returns: relative filename

lookup_override_action_filename()

Returns name of action global override file ('action_override.ini').

lookup_override_spops_filename()

Returns name of SPOPS global override file ('spops_override.ini').

lookup_session_config()

Returns 'session_info' section of server configuration (hashref).

lookup_login_config()

Returns 'login' section of server configuration (hashref).

lookup_mail_config()

Returns 'email' section of server configuration (hashref).

lookup_default_object_id( [ $name ] )

Returns the default object ID mapped to $name. If $name not given returns a hashref of all default object IDs.

lookup_id_config( [ $definition ] )

Returns the ID configuration to report what types of IDs basic OI objects are using. Normally we only care about 'user' and 'group', and we want to find out the 'type' or 'size'. So $definition will be one of 'user_type', 'user_size', 'group_type' and 'group_size'. If $definition is not given returns a hashref of all definitions.