An application can plug its most often used views into a dashboard of another application. For example, there are two system applications having dashboards for plugging application views:
The main dashboard labeled as Home is created by the system Dashboard application.
Its placeholder ID is http://www.parallels.com/ccp-dashboard#dashboard
.
Refer to the Home Dashboard document for details
and to the demo project illustrating the integration process.
The User Management system application exposes its own dashboard whose placeholder ID is
http://www.parallels.com/ccp-users#usersview
.
Refer to the User Management document for details
and to the demo project illustrating the integration process.
In this document:
In the APP-META.xml
file, a view-plugin is declared by the <view-plugin> element.
Inside it, there is a <plugs-to> element that makes the view plugged into a dashboard.
Other than that, the declaration is similar to the declaration of an ordinary view.
As follows from the code below, the application declares its view and plugs it into the Home dashboard created by the Dashboard system application.
<navigation id="plugins" label="plugins store">
<view-plugin id="DashboardPlugin" src="ui/plugins/DashboardPlugin.js">
<var name="dashboard_enabled" required="false"
type-id="http://www.parallels.com/dummyapi/context/1.0"/>
<plugs-to id="http://www.parallels.com/ccp-dashboard#dashboard"/>
</view-plugin>
</navigation>
View-plugin structure is similar to the structure of an ordinary view.
However, it does not declare the onShow
and onHide
methods.
The structure normally contains definition of a method the dashboard view calls. The method returns a widget
presenting application resources in the dashboard view.
Note
All variables declared before the declare
function definition will be shared for all
view instances based on the same source code.
Typical structure of the main init
method is as follows:
init: function (mediator) {
/* Main function for the view-plugin */
mediator.callMethod = function(data) {
/* Initialize resource parameters */
/* Initialize a widget */
var widget;
...
/* Calculate data */
/* Update the widget with calculated data */
/* Add child elements to the widget */
return widget;
}; // End of mediator.callMethod
} // End of Init
To keep displayed data up-to-date, a view-plugin processes data received from the integrated application, that is from the dashboard owner, and returns its own data to display on the dashboard as explained in the Home Dashboard document.
Warning
The parent application that gets widgets plugged into its dashboard can intentionally or non-intentionally remove some widgets. This can cause exception errors in the view-plugins.
To avoid the outlined issues, track state of the respective domNode
for the plugged widget or define
a handler for the plugged widget that is triggered whenever the widget is removed. You can implement the latter
solution by using the own
method available in any widget. This method declares a handler called
when the widget is removed by the destroy
or destroyRecursive
method. In a view-plugin, this
may look as follows:
mediator.callMethod = function(data) {
/* Initialize a widget */
var myWidget;
...
/* Define a widget die handler */
function widgetDied() {
...
}
/* Declare the widgetDied as a handler */
myWidget.own({
destroy: widgetDied,
destroyRecursive: widgetDied
});
return myWidget;
}; // End of mediator.callMethod
A view-plugin processes model data by the onContext
method the way as explained in the onContext
for a view.
The Home Dashboard demo project illustrates the process of integrating an application with a dashboard.
The Dashboard Integration
APS package contains a basic application integrated with the system Home dashboard.