Perspectives are a specialized mode added to the Pentaho User Console (PUC) for the next release of the suite (SUGAR). Active development is still very much underway, but I wanted to highlight this really cool new feature. CI builds of Sugar are available at http://ci.pentaho.com/view/Sugar/.
A perspective changes the behavior and appearance of PUC by taking over certain areas of the interface. The PUC main toolbar and main menubar are now easily setup with XUL overlays. The content area of PUC can also be completely owned by a perspective. In this way, PUC can be dramatically customized. Switching perspectives is done by clicking on them in the upper right hand corner.
From an API standpoint, registering a perspective with the system simply means adding the right objects to the perspective manager. There are two interfaces of concern here, IPluginPerspective and IPluginPerspectiveManager. IPluginPerspectiveManager is added to pentahoObjects.spring.xml making it available through PentahoSystem. The easiest way to add a perspective to the system is to simply add its definition to the plugin.xml of a plugin. However, you are not constrained to this, you can register a new perspective through the API. For example,
Implementing the interfaces
Should you decide to implement your own perspective interfaces and replace ours, there are only a few interfaces to concern yourself with. The first thing you must do is replace the IPluginPerspectiveManager in pentahoObjects.spring.xml, for example:
Once you've done this, and your class is available to the system your plugin perspective manager will be used to register perspectives. PUC will use PentahoSystem to use your manager to list the available perspectives. A perspective itself must extend IPluginPerspective, for example:
This class is just a bean and provides:
- id (unique perspective id)
- title (name of the perspective shown in PUC)
- content-url (the url of the page used to hijack PUC content area)
- resourcebundle (the uri to a message bundle for localizing the title of the perspective)
- overlays (xul overlays to apply to menu/toolbar of PUC)
- layout-priority (used to control the order which perspectives show up in PUC, BI Browser is -1)
- required-security-actions (action based security can be used to check if the user "isAllowed")
The plugin system in Pentaho has been expanded to read perspective definitions from the plugin.xml of a plugin in pentaho-solutions. Any number of perspectives can be added to a single plugin.xml.
If you want to localize the title of the perspective as it appears in PUC you'll need a resource bundle accessible to PUC at runtime. The URI is specified on the perspective definition:
The plugin "default-plugin-perspective" is a folder in pentaho-solutions/system and contains a messages.properties file located in 'default-plugin-perspective/resources/messages'. This can be made available by publishing a static-path in the plugin config:
The string $
is replaced with whatever title means in the messages.properties file (or other localized
As mentioned before, a perspective will takeover the content area of PUC when it is active. The URL for this is specified with the content-url attribute of the perspective. For example:
When this perspective is made active, index.html is loaded in an iframe in the content area of PUC.
Action based security may be used to lock perspectives down, for example, only show an "Admin" perspective to those who are allowed to see it. This is done using the existing action based security provided by the Pentaho platform. The security action for administration is "org.pentaho.security.administerSecurity". To specify this in the perspective definition:
In PUC, the order that the perspectives show up in the UI is controlled by a layout-priority attribute in the perspective node. The default perspective (BI Browser) has a value of -1. If you want your perspective to appear before this go with a lower number (such as -2).
One of the most fundamental changes to PUC for the addition of perspectives was to completely replace the menu system with a XUL approach. We already had a XUL definition for the main toolbar, now there is a XUL definition for the main menubar. This file is webapps/pentaho/mantle/xul/main_menubar.xul. You can further customize PUC by changing this XUL file. What we are interested for the purpose of perspectives is the ability to modify the toolbar and menubar with XUL overlays. A perspective can provide any number of XUL overlays which are used to add/remove/update items to the toolbar or menubar. Here is a simple example:
This XUL overlay will add a button to the main toolbar with a given image, title, tooltip, insertion point, etc. Menu items can be added anywhere in the menu system in a similar way:
This will add a menuitem under the File -> New menu. You can actually add an entirely new menu if needed. This can be done by giving a more complete definition in the XUL:
When a perspective is active, its overlays will be in play, likewise, when it becomes inactive, its overlays are removed. It is possible for a perspective's overlays to make permanent changes to the UI, instead of just when it is active. This is done simply by convention, an overlay whose "id" starts with "sticky" or "startup" will be active even when the perspective is not. Typically, you would create two overlays for a perspective, one for changes to apply when the perspective is active and another to apply because the plugin exists.
This overlay will be applied regardless of the active state of the perspective.
To read the state (enabled/disabled) of a toolbar button:
var enabled = window.top.mantle_isToolbarButtonEnabled("button.id");
To set the state of a toolbar button:
var enabled = true; // or false
To read the state of a menu item:
var enabled = window.top.mantle_isMenuItemEnabled('menuitem.id'))
To set the state of a menu item:
We have also made it easier to bridge between the XUL/GWT world for defining what happens when you press a button or select a menu item. Of course, there are the existing techniques, referencing the handler and a bound function to invoke a well known PUC command, for example:
js-command attribute in the XUL definition. For example:
To invoke this function from a toolbar button or menu item:
This example has been checked in along with the existing sample plugin perspective.