$_topic
$_topic : \midcom_db_topic
The topic for which we are handling a request.
Deliverable processing class
Use the various event handlers to customize startup.
The basic idea is that you have separate instances of this type for the various operations in your main viewer class. This avoids cluttering up the viewer class and gives you better maintainability due to smaller code files.
Under normal operation within the same component you don't need to think about any specialties, the member variables are just references to the main request class (also known as "viewer class").
Noteworthy is the ability to export handlers for usage in other components in both libraries and full components. To make the exported handler work correctly, you need to set $this->_component to the corresponding value of the exporting component. In this case, the startup code will take the main l10n instance, the component data storage and the configuration from the exporting component. The configuration in this case is merged from the global defaults (constructed during component/library startup) and the configuration parameters set on the topic where it is invoked.
Note, that the export "mode" is only invoked if and only if the component of the handler is different of the component of the main request class.
$_topic : \midcom_db_topic
The topic for which we are handling a request.
$_master : \midcom_baseclasses_components_request
The request class that has invoked this handler instance.
$_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.
$_deliverable : \org_openpsa_sales_salesproject_deliverable_dba
The deliverable we're working with
$_salesproject : \org_openpsa_sales_salesproject_dba
The salesproject the deliverable is connected to
initialize(\midcom_baseclasses_components_request $master, \Symfony\Component\Routing\Router $router)
Initializes the request handler class, called by the component interface after instantiation.
Be aware that it is possible that a handler can come from a different component (or library) than the master class. Take this into account when getting the component data storage, configuration and l10n instances. Configuration is merged during runtime based on the system defaults and all parameters attached to the topic we're currently operating on.
| \midcom_baseclasses_components_request | $master | The request class |
| \Symfony\Component\Routing\Router | $router |
show(string $element) : \midcom_response_styled
Generates a response with a given style element
| string | $element |
bind_view_to_object(\midcom_core_dbaobject $object, string $page_class = 'default')
Binds the current page view to a particular object. This will automatically connect such things like metadata and toolbars to the correct object.
| \midcom_core_dbaobject | $object | The DBA class instance to bind to. |
| string | $page_class | String describing page type, will be used for substyling |
get_workflow(string $identifier, array $options = array()) : \midcom\workflow\dialog
| string | $identifier | |
| array | $options |