...
The drill-linking UI is integrated into the core of the Pentaho Report Designer. Each drilldown-group can have a corresponding "drilldown-ui-plugin". At the moment, there are three UI plugins defined:
(1) Self-Linking
A special linking mode that takes all declared parameter and creates a URL that calls the same report with possibly changed parameter values. This linking mode facilitates self-service reporting solutions. An example would be a report where users alter the sorting of columns or browse through a paginated result set.
(2) Generic URL linking
Allows to link to any url. This mode allows to construct links to external services that do not provide parameter information. Generic-URL linking assists in the error-prone process of computing parameter sets for URLs.
(3) Pentaho Content Linking
This Drilldown-UI-Plugin connects the drill-down function to the Pentaho BI-Server. It assumes that all linkable content has a parameter-service that returns proper parameter description documents.
A typical edit session
When editing the user either enters a server address to create a remote link (a link that drills to a report stored on a different server) or leaves the server field empty to create a local link.
The user hits login to login to the server. If the server field is empty, the report's current authentication data is used. A report that was opened from a Pentaho repository already has valid login information, which will be used. Otherwise we prompt the user for the server adress and username and password.
The user browses the solution repository for a target report. If the user has not logged in, the login is done before the browsing starts. The browse-dialog only shows files for which a drill-down profile exists. The files are selected by their extension, which has to match a "extension" attribute from one of the drill-down profiles used.
When the user selected a file, the parameter for this file are queried. The file location is stored in the system parameters "solution", "path" and "name" ("action" for xaction and xanalyzer).
The Drill-Down-UI-Profile fills the available parameter into the parameter table. The user can then set values or add additional parameter that are not available in the parameter-description. The parameter table allows users to enter formula fragments or static values.
The UI takes all user input and produces a valid openformula formula expression with a single "DRILLDOWN" function in it.
When the user hits OK on the "Edit Hyperlink" dialog, this drill-down function is added to as "href" style expression.
If the expression on the "href" style cannot be interpreted as a DRILLDOWN function, the report designer falls back to the legacy editor and allows users to edit the formula function in the Formula-editor.
2.2.3 Architecture of the UI code
As PRD is a Swing application, the UI code is heavily dependent on Swing concepts. For each DrillDown-Group, the drilldown-ui-registry contains a corresponding entry. DrillDownUIProfile must have the same name as the drilldown-group for which it provides a UI.
The DrillDownUiProfile acts as configuration holder and template. It is a factory that produces DrillDownUi instances. DrillDownUiProfiles are immutable and encapsulate the metadata for the available DrillDownUI implementations.
A DrillDownUi is a stateful editor for the DrillDown-formula function. It shares a common DrillDownModel with all active DrillDownUI implementations. The DrillDownModel encapsulates the editor state. DrillDownUI editor should update the DrillDownModel as soon as possible.
After the Ui was instantiated, it will be immediately initialized via a call to the "init" method. The UI has to fully initialize itself from the given model. The DrillDownUi provides a Swing component to the editor dialog via the "getEditorPanel" method. At the end of the editor's life-cycle, the "deactivate" method is called. The XulDrillDownUi classes can be used to separate the UI layout definition from the actual UI-handling and model code.
3. Implementing additional DrillDown-Profiles
asd
4. Implementing conditional Generator Modes
asd
2.2 Frontend Architecture
The frontend code consists of a extension module for the Pentaho Report Designer
and a extension to the Pentaho BI-Server that generates Parameter information for
the known content types.
The front end code has the purpose to allow an user to create a DRILLDOWN formula
function. For that the UI has to select a "drilldown-config", possibly ask the user
for a "path" and then collect the parameter name-value pairs.
The UI should be pluggable. This allows system integrators to define new drilldown
profiles in the backend and to integrate them into the existing user interface.
When a user links to Pentaho-Platform link-targets, the system must offer the
existing parameter on the target object to the user.
2.2.1 Platform Parameter service
In most cases, the Pentaho Platform already knows the parameter of their objects.
XActions, XAnalyzer and PRPT objects already contain parameter declarations. Since
BI-Server 3.7, the Pentaho Reporting Plugin's parameter format is the standard format
to describe parameter information in the platform.
The solution repository service knows the location of a "parameter-service-url"
for each object that supports parameter. A external programm like PRD can use this
URL to request parameter information from the Pentaho Platform.
The format of the parameter document is defined in the following XML-Schema: http://source.pentaho.org/viewvc/svnroot/platform-plugins/reporting-plugin/branches/3.7/parameters.xsd
A BI-Server plugin declares that it has a parameter service by declaring a content-type
operation with the id "PARAMETER":
| Code Block |
|---|
<plugin title="Pentaho Reporting Plugin">
..
<content-types>
<content-type type="prpt" mime-type="application/zip">
..
<operations>
..
<operation>
<id>PARAMETER</id>
<command>content/reporting/?renderMode=PARAMETER&solution={solution}&path={path}&name={name}</command>
</operation>
</operations>
..
</content-type>
</content-types>
|
A call to this URL must result in a XML document that compiles to the parameter-definition
schema given above.
The parameter XML should contain both the user defined parameter as well as any
system level parameter. Parameter that are not meant to be seen by the user in any
parameter entry UI should be marked as hidden by setting the appropriate parameter
attribute.
<Here table of known attributes and their meanings>
2.2.2 PRD extension
The drill-linking UI is integrated into the core of the Pentaho Report Designer.
Each drilldown-group can have a corresponding "drilldown-ui-plugin". At the moment,
there are three UI plugins defined:
(1) Self-Linking
A special linking mode that takes all declared parameter and creates a URL that
calls the same report with possibly changed parameter values. This linking mode
facilitates self-service reporting solutions. An example would be a report where
users alter the sorting of columns or browse through a paginated result set.
(2) Generic URL linking
Allows to link to any url. This mode allows to construct links to external services
that do not provide parameter information. Generic-URL linking assists in the
error-prone process of computing parameter sets for URLs.
(3) Pentaho Content Linking
This Drilldown-UI-Plugin connects the drill-down function to the Pentaho BI-Server.
It assumes that all linkable content has a parameter-service that returns proper parameter
description documents.
A typical edit session
When editing the user either enters a server address to create a remote link
(a link that drills to a report stored on a different server) or leaves the
server field empty to create a local link.
The user hits login to login to the server. If the server field is empty, the
report's current authentication data is used. A report that was opened from a
Pentaho repository already has valid login information, which will be used.
Otherwise we prompt the user for the server adress and username and password.
The user browses the solution repository for a target report. If the user has
not logged in, the login is done before the browsing starts. The browse-dialog
only shows files for which a drill-down profile exists. The files are selected
by their extension, which has to match a "extension" attribute from one of the
drill-down profiles used.
When the user selected a file, the parameter for this file are queried. The file
location is stored in the system parameters "solution", "path" and "name" ("action"
for xaction and xanalyzer).
The Drill-Down-UI-Profile fills the available parameter into the parameter table.
The user can then set values or add additional parameter that are not available
in the parameter-description. The parameter table allows users to enter formula
fragments or static values.
The UI takes all user input and produces a valid openformula formula expression
with a single "DRILLDOWN" function in it.
When the user hits OK on the "Edit Hyperlink" dialog, this drill-down function
is added to as "href" style expression.
If the expression on the "href" style cannot be interpreted as a DRILLDOWN
function, the report designer falls back to the legacy editor and allows users
to edit the formula function in the Formula-editor.
2.2.3 Architecture of the UI code
As PRD is a Swing application, the UI code is heavily dependent on Swing concepts.
For each DrillDown-Group, the drilldown-ui-registry contains a corresponding entry.
DrillDownUIProfile must have the same name as the drilldown-group for which it
provides a UI.
The DrillDownUiProfile acts as configuration holder and template. It is a factory
that produces DrillDownUi instances. DrillDownUiProfiles are immutable and encapsulate
the metadata for the available DrillDownUI implementations.
A DrillDownUi is a stateful editor for the DrillDown-formula function. It shares
a common DrillDownModel with all active DrillDownUI implementations. The DrillDownModel
encapsulates the editor state. DrillDownUI editor should update the DrillDownModel
as soon as possible.
After the Ui was instantiated, it will be immediately initialized via a call to the
"init" method. The UI has to fully initialize itself from the given model.
The DrillDownUi provides a Swing component to the editor dialog via
the "getEditorPanel" method. At the end of the editor's life-cycle, the "deactivate"
method is called. The XulDrillDownUi classes can be used to separate the UI layout
definition from the actual UI-handling and model code
The UI takes all user input and produces a valid openformula formula expression with a single "DRILLDOWN" function in it. When the user hits OK on the "Edit Hyperlink" dialog, this drill-down function is added to as "href" style expression.
If the expression on the "href" style cannot be interpreted as a DRILLDOWN function, the report designer falls back to the legacy editor and allows users to edit the formula function in the Formula-editor.
At the moment, there are three UI plugins defined:
(1) Self-Linking
A special linking mode that takes all declared parameter and creates a URL that calls the same report with possibly changed parameter values. This linking mode facilitates self-service reporting solutions. An example would be a report where users alter the sorting of columns or browse through a paginated result set.
(2) Generic URL linking
Allows to link to any url. This mode allows to construct links to external services that do not provide parameter information. Generic-URL linking assists in the error-prone process of computing parameter sets for URLs.
(3) Pentaho Content Linking
This Drilldown-UI-Plugin connects the drill-down function to the Pentaho BI-Server. It assumes that all linkable content has a parameter-service that returns proper parameter description documents.
A typical edit session
When editing the user either enters a server address to create a remote link (a link that drills to a report stored on a different server) or leaves the server field empty to create a local link.
The user hits login to login to the server. If the server field is empty, the report's current authentication data is used. A report that was opened from a Pentaho repository already has valid login information, which will be used. Otherwise we prompt the user for the server adress and username and password.
The user browses the solution repository for a target report. If the user has not logged in, the login is done before the browsing starts. The browse-dialog only shows files for which a drill-down profile exists. The files are selected by their extension, which has to match a "extension" attribute from one of the drill-down profiles used.
When the user selected a file, the parameter for this file are queried. The file location is stored in the system parameters "solution", "path" and "name" ("action" for xaction and xanalyzer).
The Drill-Down-UI-Profile fills the available parameter into the parameter table. The user can then set values or add additional parameter that are not available in the parameter-description. The parameter table allows users to enter formula fragments or static values.
The Pentaho-Drilldown-UI profile contains extra logic to handle a set of PRPT specific drilldown profile selections. The PRPT component can be executed with or without the parameter UI. In those cases, separate URLs need to be generated.
Each Pentaho profile can either be a local profile (linking to content on the same server) or remote content (linking to a different server). For this condition two separate drill-down profiles exist, one prefixed with "local-" and one prefixed with "remote-". The UI dynamically selects the appropriate one based on the selection of a "Include Server URL in Link" checkbox.
2.2.3 Architecture of the UI code
As PRD is a Swing application, the UI code is heavily dependent on Swing concepts. For each DrillDown-Group, the drilldown-ui-registry contains a corresponding entry. DrillDownUIProfile must have the same name as the drilldown-group for which it provides a UI.
The DrillDownUiProfile acts as configuration holder and template. It is a factory that produces DrillDownUi instances. DrillDownUiProfiles are immutable and encapsulate the metadata for the available DrillDownUI implementations.
A DrillDownUi is a stateful editor for the DrillDown-formula function. It shares a common DrillDownModel with all active DrillDownUI implementations. The DrillDownModel encapsulates the editor state. DrillDownUI editor should update the DrillDownModel as soon as possible.
After the Ui was instantiated, it will be immediately initialized via a call to the "init" method. The UI has to fully initialize itself from the given model. The DrillDownUi provides a Swing component to the editor dialog via the "getEditorPanel" method. At the end of the editor's life-cycle, the "deactivate" method is called. The XulDrillDownUi classes can be used to separate the UI layout definition from the actual UI-handling and model code.
3. Implementing additional DrillDown-Profiles
Backend:
- Create a new entry in the drilldown-profiles.xml.
- Add the metadata and the resource-bundle information
- Add a formula or pattern (depending on the customizer used) that creates the URL for you.
Frontend: Implementing a Pentaho Service:
- Implement a parameter service for your content generator plugin in the server and register it as content-type operation "PARAMETER".
- Add the "extension" property to the backend definition and ensure that you define both a "local" and a "remote" profile for your service.
Frontend: Implement a 3rd Party Parameter Service
Implement a parameter service for your content so that your UI can query parameter information. Alternatively you can hardcode the available parameter into your UI or you can reuse the parameter-xml code from the pentaho-drilldown-ui to read a xml file from your server.
Implement a UI plugin. I would recommend to use the "Generic URL" UI-plugin as starting point. With this code as basis you only have to implement the browse and code that populates the parameter-table.