Hitachi Vantara Pentaho Community Wiki
Child pages
  • Using AJAX to Drive Dependent Report Parameters

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Open the DependentParameterExample.xaction in the Pentaho Design Studio. You can do this by navigating to the dep-param directory in our solution's project, and double-clicking on the DependentParameterExample.xaction file.
  2. In the Process Inputs box at the top of the page, you should see an inputs folder. Expand that folder using the plus sign next to the folder. In the inputs folder are the six inputs needed for our simple solution. We need three String inputs to hold the three selections that the user will specify: REGION, DEPARTMENT and POSITIONTITLE. Then we also need a String-list input to hold the available values for each of the three selections: that would be the REGION_FILTER, DEPARTMENT_FILTER and POSITIONTITLE_FILTER.
  3. Click on the REGION_FILTER String-list input. Notice that the Default Value checkbox is checked, and there are 4 hard coded values in the defaults list. We have hard coded the region values for the REGION selection, ONLY for the sake of simplicity. We could have used a SQL Lookup Rule to populate the REGION_FILTER values, but instead wanted to keep the example as simple as possible.
  4. The DEPARTMENT_FILTER values are also hard coded, in order to keep things simple. Click the DEPARTMENT_FILTER String-list input, and you will see it too has several default values.
  5. We start the action sequence by running a query to populate the POSITIONTITLE_FILTER String-list. Click on the first action in the Process Actions box, labeled "Perform SQL Query". You can examine the details of this action, and see that the query is retrieving all position titles from the database, and the resultset is being stored in the POSITIONTITLE_FILTER input.

    At this point , you might ask, why are we populating the position title list now? We don't know what department the user will choose, so we will throw this list away anyway when we issue the command to retrieve only those position titles related to the chosen department. This is a bit of awkwardness that is necessary becuase of the nature of the Secure Filter Component. You see, the Secure Filter Component requires that, at the time of execution, it has a valid list of selections to validate the user's choice against. This prevents hackers from introducing values into the action sequence that could be potentially harmful or could expose confidential data. When we execute the Secure Filter Component at the beginning of the action sequence, we don't know what department will be selected, so we can't populate the filtered list of position titles. But we can start out with the COMPLETE list of position titles from the database, thus any department that is chosen later on will always send a list of valid position titles for the user to choose from, satisfying the Secure Filter Component's requirements.
  6. Our next step is to define our Secure Filter Component, that will generate the parameter page, prompting our user for the 3 selections we set up inputs for: REGION, DEPARTMENT, and POSITIONTITLE. Select the second action in the Process Actions box, titled "Prompt For Region, Dept, and Output Type".
  7. Click on each of the parameters in the "Prompt For" box in the right hand pane. Notice that these parameters are set up pretty standard: the String input is reserved to hold the user's selection and the list of choices (Source of Choices in the right pane) is coming from the String-list inputs we defined .
  8. The magic of populating the position title combo box based on the department selection comes from changing the template that the Secure Filter Component uses to render the parameter page. Notice in the Stylesheet field on the right pane, it lists our DependentParameterTemplate.html. That is a means for bringing the DependentParameterTemplate.html file into our action sequence.
    Image Added
    The DependentParameterTemplate.html file is the template we are telling our Secure Filter Component to use. We will take a look at DependentParameterTemplate.html in greater detail in a moment, but first let's finish examining this action sequence.
  9. The last step in our action sequence executes after the Secure Filter Component has completed its work. The last action takes the values selected by the user and queries the database using those values as parameters in the query. If you are not familiar with parameterized queries or the PREPARE statement, you can learn more in this technical article.