MidCOM context handling

Provides a basic context mechanism that allows each independent component invocation to access its own context information.

package midcom

 Methods

__construct (int $id, \MidgardObject $node)

Create and prepare a new component context.

Parameters

$id

intExplicitly specify the ID for context creation (used during construction), this parameter is usually omitted.

$node

\MidgardObjectRoot node of the context

Returns

intThe ID of the newly created component.

get (int $id)

Get context, either the current one or one designated by ID
Static

If the current context is requested and doesn't exist for some reason, it is automatically created

Parameters

$id

intThe context ID, if any

Returns

\midcom_core_contextThe requested context, or false if not found

get_all ()

Returns the complete context data array
Static
todo This should be removed and places using this rewritten

Returns

arrayThe data of all contexts

get_custom_key (int $key, string $component)

Retrieve arbitrary, component-specific information in the component context

The set call defaults to the current context, the get call's semantics are as with get_context_data.

Note, that if you are working from a library like the datamanager is, you cannot override the component association done by the system. Instead you should add your libraries name (like midcom.helper.datamanager) as a prefix, separated by a dot. I know, that this is not really an elegant solution and that it actually breaks with the encapsulation I want, but I don't have a better solution yet.

A complete example can be found with set_custom_key.

see \get_key()
see \set_custom_key()

Parameters

$key

intThe requested key

$component

stringThe component name

Returns

mixedThe requested value, which is returned by Reference!

get_handler (\midcom_db_topic $object)

Check whether a given component is able to handle the current request.

Used by midcom_application::_process(), it checks if the component associated to $object is able to handle the request. After the local configuration is retrieved from the object in question the component will be asked if it can handle the request. If so, the interface class will be returned to the caller

Parameters

$object

\midcom_db_topicThe node that is currently being tested.

Returns

mixedThe component's interface class or false

get_key (int $key)

Access the MidCOM component context

Returns Component Context Information associated to the component with the context identified by $key.

Parameters

$key

intThe key requested

Returns

mixedThe content of the key being requested.

run (\midcom_baseclasses_components_interface $handler)

Handle a request.

The URL of the component that is used to handle the request is obtained automatically. If the handler hook returns false (i.e. handling failed), it will produce an error page.

Parameters

$handler

\midcom_baseclasses_components_interfaceThe component's main handler class

set_current ()

Marks context as current

Returns

booleanIndicating if the switch was successful.

set_custom_key (mixed $key, mixed $value, string $component)

Store arbitrary, component-specific information in the component context

This method allows you to get custom data to a given context. The system will automatically associate this data with the component from the currently active context. You cannot access the custom data of any other component this way, it is private to the context. You may attach information to other contexts, which will be associated with the current component, so you have a clean namespace independently from which component or context you are operating of. All calls honor references of passed data, so you can use this for central controlling objects.

Note, that if you are working from a library like the datamanager is, you cannot override the component association done by the system. Instead you should add your libraries name (like midcom.helper.datamanager) as a prefix, separated by a dot. I know, that this is not really an elegant solution and that it actually breaks with the encapsulation I want, but I don't have a better solution yet.

Be aware, that this function works by-reference instead of by-value.

A complete example could look like this:

class my_component_class_one {
    function init () {
        midcom_core_context::get()->set_custom_key('classone', $this);
    }
}

class my_component_class_two {
       var one;
    function my_component_class_two () {
        $this->one =& midcom_core_context::get()->get_custom_key('classone');
    }
}
see \get_custom_key()

Parameters

$key

mixedThe key associated to the value.

$value

mixed&$value The value to store. (This is stored by-reference!)

$component

stringThe component associated to the key.

set_key (int $key, mixed $value)

Update the component context

This function sets a variable of the current or the given component context.

see \get_context_data()

Parameters

$key

intThe key to use

$value

mixedThe value to be stored

_loadconfig (int $context_id, \midcom_db_topic $object)

Load the configuration for a given object.

This is a small wrapper function that retrieves all local configuration data attached to $object. The assigned component is used to determine which parameter domain has to be used.

Parameters

$context_id

intThe context ID

$object

\midcom_db_topicThe node from which to load the configuration.

Returns

\midcom_helper_configurationReference to the newly constructed configuration object.

 Properties

 

int $id

The context's ID
 

\midcom_core_service_urlparser $parser

The context's URL parser instance
 

array $_contexts

Holds the component context information.

This is an array of arrays, the outer one indexed by context IDs, the inner one indexed by context keys. Only valid of the system has left the code-init phase.

 

int $_currentcontext

Contains the ID of the currently active context
 

array $_data

The context's data