$id
$id : integer
The context's ID
MidCOM context handling
Provides a basic context mechanism that allows each independent component invocation to access its own context information.
$parser : \midcom_core_service_urlparser
The context's URL parser instance
$_contexts : array<mixed,\midcom_core_context>
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.
__construct(integer $id = null, \midcom_db_topic $node = null)
Create and prepare a new component context.
| integer | $id | Explicitly specify the ID for context creation (used during construction), this parameter is usually omitted. |
| \midcom_db_topic | $node | Root node of the context |
get(integer $id = null) : \midcom_core_context
Get context, either the current one or one designated by ID
If the current context is requested and doesn't exist for some reason, it is automatically created
| integer | $id | The context ID, if any |
The requested context, or false if not found
get_all() : array<mixed,\midcom_core_context>
Returns the complete context data array
All contexts
get_custom_key(integer $key, string $component = null) : mixed
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_key().
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.
| integer | $key | The requested key |
| string | $component | The component name |
The requested value, which is returned by Reference!
set_custom_key(mixed $key, $value, string $component = null)
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 {
public function init () {
midcom_core_context::get()->set_custom_key('classone', $this);
}
}
class my_component_class_two { public $one; public function __construct() { $this->one =& midcom_core_context::get()->get_custom_key('classone'); } }
| mixed | $key | The key associated to the value. |
| $value | ||
| string | $component | The component associated to the key. |
run(\Symfony\Component\HttpFoundation\Request $request) : \midcom_response
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.
| \Symfony\Component\HttpFoundation\Request | $request |
handle(\midcom_db_topic $topic, \Symfony\Component\HttpFoundation\Request $request = null) : \midcom_response
Check whether a given component is able to handle the current 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
| \midcom_db_topic | $topic | The node that is currently being tested. |
| \Symfony\Component\HttpFoundation\Request | $request |
_loadconfig(integer $context_id, \midcom_db_topic $topic) : \midcom_helper_configuration
Load the configuration for a given object.
This is a small wrapper function that retrieves all local configuration data attached to $topic. The assigned component is used to determine which parameter domain has to be used.
| integer | $context_id | The context ID |
| \midcom_db_topic | $topic | The node from which to load the configuration. |
The newly constructed configuration object.