$_topic
$_topic : \midcom_db_topic
The topic for which we are handling a request.
Comments site interface class
See the various handler classes for details.
$_topic : \midcom_db_topic
The topic for which we are handling a request.
$_config : \midcom_helper_configuration
The current configuration.
$_node_toolbar : \midcom_helper_toolbar
The node toolbar for the current request context. Not available during the can_handle phase.
$_view_toolbar : \midcom_helper_toolbar
The view toolbar for the current request context. Not available during the can_handle phase.
$_request_switch : array
Request execution switch configuration.
The main request switch data. You need to set this during construction, it will be post-processed afterwards during initialize to provide a unified set of data. Therefore you must not modify this switch after construction.
$_plugin_namespace_config : array
This variable keeps track of the registered plugin namespaces. It maps namespace identifiers against plugin config lists. This is used during can_handle startup to determine whether the request has to be relayed to a plugin.
You have to use the register_plugin_namespace() member function during the _on_initialize event to register plugin namespaces.
can_handle(\Symfony\Component\HttpFoundation\Request $request) : boolean
CAN_HANDLE Phase interface, checks against all registered handlers if a valid one can be found. You should not need to override this, instead, use the HANDLE Phase for further checks.
| \Symfony\Component\HttpFoundation\Request | $request |
Indicating whether the request can be handled by the class, or not.
handle() : \midcom_response|null
Handle the request using the handler determined by the can_handle check.
Before doing anything, it will call the _on_handle event handler to allow for generic request preparation.
The response object (or null in the case of old-style handlers)
_on_initialize()
Initialization event handler, called at the end of the initialization process
Use this function instead of the constructor for all initialization work. You can safely populate the request switch from here.
You should not do anything else then general startup work, as this callback executes before the can_handle phase. You don't know at this point whether you are even able to handle the request. Thus, anything that is specific to your request (like HTML HEAD tag adds) must not be done here. Use _on_handle instead.
_on_handle(mixed $handler, array $args)
Generic request startup work: - Populate the Node Toolbar depengin on the user's rights
Note, that while you have the complete information around the request (handler id, args and request data) available, it is strongly discouraged to handle everything here. Instead, stay with the specific request handler methods as far as sensible.
| mixed | $handler | The ID (array key) of the handler that is responsible to handle the request. |
| array | $args | The argument list. |
register_plugin_namespace(string $namespace, array $config)
Create a new plugin namespace and map the configuration to it.
It allows flexible, user-configurable extension of components.
Only very basic testing is done to keep runtime up, currently the system only checks to prevent duplicate namespace registrations. In such a case, midcom_error will be thrown. Any further validation won't be done before can_handle determines that a plugin is actually in use.
| string | $namespace | The plugin namespace, checked against $args[0] during URL parsing. |
| array | $config | The configuration of the plugin namespace as outlined in the class introduction |
get_workflow(string $identifier, array $options = array()) : \midcom\workflow\dialog
| string | $identifier | |
| array | $options |
_load_plugin(string $namespace, string $name)
Load the specified namespace/plugin combo.
Any problem to load a plugin will be logged accordingly and false will be returned. Critical errors will trigger midcom_error.
| string | $namespace | The plugin namespace to use. |
| string | $name | The plugin to load from the namespace. |