Query-based input controls display a dynamic set of values for the user to choose from. They are input control resources in the repository, but instead of being based on a datatype or a static list of values, they perform a query to retrieve a list of values. For example, a report could have a city parameter, and the query-based input control could display the list of cities that exist in your data. Because the queries use standard syntax, you can include filters in a WHERE clause. In the previous example, you could restrict the list of cities to a certain country.

By including parameters, you can also create cascading input controls. A cascading input control is one whose choices depend on the selection of a previous input control. For example, after the user selects a country, the available city values are restricted to the chosen country. Cascading input controls are query-based controls that contain parameters returned by other controls.

Cascading input controls help make input controls easier to use and faster to display. Certain parameters in reports have a natural hierarchy, such as countries and cities or years and quarters, and the cascading input controls let the user find values based on this hierarchy. Instead of selecting cities from one large list that may need to scroll, users can make a selection from a smaller list where all choices are visible. Also, displaying long lists make the web page slow to load, so cascading input controls that reduce the size of the list make it faster to load. If there were an especially large number of cities, more cascading input controls could be used to reduce the list, such as region or state. The values for each control are loaded only when the previous input has been selected, making for a convenient and speedy user experience.

The parameter values determined by each cascading input control may or may not be used in the report. For example, if the report only shows data about a city, the country input control exists only to speed up the choice of city. However, if the report also shows information such as city average compared to country average for a given measure, the country parameter is also used in the report.

Creating a Query-based Input Control

In this first example, we create a query-based input control that returns a long list of all cities for the user to choose from.

If you have a suitable query resource defined in the repository, you could select it here as an external reference. In this example, we’ll define a query resource locally inside the input control resource.

Although the query resource is not visible in the repository, it may still have a name, ID and optional description within the query resource. However, the values for these fields are not important.

As with all query resources, the query resource inside the input control may optionally link to a data source, either in the repository, or its own internally defined one. If no data source is linked, the query in the input control uses the same data source as report. In this example, we take the default selection of not linking to a data source.

For an example in a different query language, see Domain-based Queries.

On the parameter values page, you define which field in the results of the query are displayed, and which field contains values that become the parameter value when chosen.

Los Angeles | CA

San Francisco | CA

Denver | CO

Only the city value (without the state) is passed to the report. Showing additional field in this way can help users find the value they want in long lists of results.

The value and display columns may also be entirely different, for example, displaying the full name of a sales representative, but using the employee ID as the value returned by the input control. The only restriction is that all fields used in the value or display list must be selected by the query.

Built-in Parameters for Query-based Input Controls

The LoggedInUser and LoggedInUsername parameters are always available for query input controls; they are always available to reports, as well, even if an input control isn’t defined for them. The standard parameters are also provided for reports if they are defined as parameters in the JRXML.

Built-in Parameters for Query-based Input Controls

Parameter Name

Type

Notes

LoggedInUser

User

The user that is currently logged in. This parameter isn’t available in query input controls, but is used as a parameter to the report.

LoggedInUsername

String

The user name of the current user.

LoggedInUserFullName

String

The full name of the current user.

LoggedInUserEmail
Address

String

The email address of the current user.

LoggedInUserEnabled

Boolean

Indicates whether the current user is enabled.

LoggedInUserExternally
Defined

Boolean

Indicates whether the current user is authenticated externally.

LoggedInUserTenantId

String

In the commercial editions, the name of the organization of the current user.

LoggedInUserRoles

Collection
<String>

The roles assigned to the current user. This is helpful for parameters that use $X.

LoggedInUserAttributes

Map<String, String>

The profile attributes of the logged-in user. This parameter isn’t usable in query input controls, but it is used as a parameter to the report. If the user has no attributes, the parameter is an empty map.

LoggedInUserAttribute
Names

Collection
<String>

The names of the profile attributes of the logged-in user. This is helpful for parameters that use $X. If the user has no attributes, the parameter is an empty map.

LoggedInUserAttribute
Values

Collection
<String>

The values of the profile attributes of the logged-in user. This is helpful for parameters that use $X. If the user has no attributes, the parameter is an empty map.

LoggedInUserAttribute_
<attribute-name>

String

For the logged-in user, the value of the attribute matching the name passed as <attribute-name> (like att1). If there is no match, the parameter is empty.

This parameter is only available if it is defined in a query or as a report parameter.

Domain-based Queries

In the case of reports that use a Domain as the data source (an option available in the professional edition of JasperReports Server), any query-based input controls must contain a query against the Domain. When defining the query as shown in Adding an Input Control - Defining the Query, set the query language to Domain.

Domain queries have their own special syntax, the same that is used in the Domain design. A Domain-based query references fields, called items, by their item IDs, along with any set IDs that determine the path of the item within the Domain. For example, if you want your query input control to return a list store cities, where the field with ID ej_store_store_city is nested in the set with ID expense_join_store, you would use the following Domain query:

The list contained inside the <queryFields> tag in a Domain query is equivalent to the fields given in the SELECT statement of an SQL query. Given the query above, you can create an input control for a Domain-based report that lets the user select a city as a parameter to the report.

Sometimes, you may want the input control to display more information than the actual value returned. As with standard query-based input controls, you can select more fields, and then display those fields in your input control. For example, to make the list of cities unambiguous, you could include the state and country in your display. In that case, the Domain-based query must also retrieve those items:

Then, when specifying your visible query columns, as shown in The COUNTRY Input Control, you would add the 3 fields to the list in the order you want them to appear. When specifying fields in the list of visible query columns, use the full ID of the field, including any set IDs. For example, the following list of fields:

expense_join_store.ej_store_store_country

expense_join_store.ej_store_store_state

expense_join_store.ej_store_store_city

creates a list of values such as the following for users to choose from (the separator | is added automatically):

USA | CA | Los Angeles

USA | CA | San Francisco

USA | OR | Portland

USA | WA | Redmond

Finally, the Domain-based query also has the option to filter the query results, as shown in the following example:

The <queryFilterString> tag contains a DomEL (Domain Expression Language) expression that references the full ID of the fields, including any set IDs. For more information about DomEL, see the JasperReports Server User Guide. The <queryFilterString> tag in a Domain query is equivalent to the WHERE clause of an SQL query. The list of fields in the <queryFields> tag must include all fields being referenced in the filter string.

Cascading Input Controls

A cascading input control is one whose values depend on the selection made in a previous input control. Cascading input controls are created by using parameters in the query string of a related input control. In other words, the parameter defined by an input control may be used in another query-based input control.

In the query-based example of cities and states such as:

Los Angeles | CA

San Francisco | CA

Denver | CO

the query may still generate a list of hundreds of cities to scroll through. Even though each city is easy to identify with the state, scrolling through a long list is time consuming. With cascading input controls, this example can have two input controls, one for the state and one for the city:

The user makes two selections from much shorter lists, which is easier and quicker than using one long list of city and state names. The second input control is empty, showing no selections, until clicking on the first of the cascading input controls. If the user changes the state in the first control, the list of cities in the second control updates accordingly.

Parameters in Input Control Queries

Parameter substitution in query input controls follows the same approach as for JasperReports queries. Queries of all types of data sources can use parameter substitution, and $P, $P! and $X (for SQL queries) parameters are supported. The $X notation has two principal forms explained in the following list:

The value of the parameter is substituted into the query. In cases where the parameter contains a string, the substitution mechanisms inserts the proper escape characters to create valid SQL. Use this for with single-select input controls and simple comparison operators such as greater-than or less-than. For example:

select name from EMPLOYEES where deals_closed > $P{DEALS}

Do not use $P{parameter_name} with equality because the parameter value can be null, and field = NULL is not valid SQL. Instead use $X{EQUALS, ...} as explained below.

The value of the parameter is treated as raw text. The server replaces the parameter with the value of the input control without performing extra checking or value escaping. This is used in complex cases where the input control provides a piece of the query or sometimes the entire query.

This syntax performs equality verification and handles the case when the parameter value is null. Use this everywhere instead of the old column = $P{parameter_name} syntax. The $X{EQUALS...} syntax performs the following substitution before submitting the query:

column = parameter_value -- when parameter_value is non-null

column IS NULL -- when parameter_value is NULL

Use this parameter for cascading with multiple-select input controls. The $X{IN...} operator is true when the field value matches any one of the multiple values of the input control. In the country/cities example, we can allow the user to pick any number of countries, and show all the cities in the selected countries. The query-based input control would have the following query:

select city from ACCOUNTS where $X{IN, country, COUNTRIES}

If the user selects the values Canada, Mexico, and USA in the COUNTRIES multi-select input control, the $X{} syntax translates into the following query for the CITIES input control:

select city from ACCOUNTS where country IN ('USA','Canada','Mexico')

The $X syntax also supports the following operators. They are all designed to handle null input by generating 0 = 0 when the parameter value is null:

For more information on using $P, $P! and $X to build dynamic queries, refer to the JasperReports Ultimate Guide and the iReport Ultimate Guide.

The number of parameters that can be used in a query is arbitrary, just as the number of input controls that can be defined in a JasperReport is arbitrary. In addition to the standard input control parameters, a cascading input control query can use the built-in parameters described in Built-in Parameters for Query-based Input Controls.

Step-by-Step Example

In this example, we’ll create a simple report where users select a country and then a city to display all the accounts of a city, using the SugarCRM sample database shipped with JasperReports Server. This example uses iReport to create a report and its input controls. iReport uses the JasperReports Server plug-in to upload these resources to the repository.

We start by creating a report with a parameter called CITY and the following report query:

select * from accounts where $X{EQUALS, billing_address_city, CITY}

In the detail band, we add three fields: name, shipping_address_city, and shipping_address_country. Then we publish the report on the server, using the Publish tool of the JasperReports Server plug-in in iReport.

Now define the input controls. Right-click the JasperReport node in the Repository Navigator and add the first input control by selecting Add > Input Control. This input control shows the list of countries in which accounts are present. It is not a cascading input control, but its value is used in the next control: the one that selects the city.

Set the name of this first input control to COUNTRY (the display name can be “Country”). Set the Input Control type to Single Select Query. Edit a local resource for the query, set a name for it (“query”) and set the query language to SQL.

The query is just a simple query to select the countries. For instance:

To complete the local query resource, set the repository resource /datasources/JServerJdbcDS as the query’s data source. Finally, in the Value and Visible Columns tab, set the Value Column to shipping_address_country and make it (the only) visible column. The first input control, which selects the country, is now ready.

Now that we have an input control named COUNTRY, we can reference the COUNTRY parameter in another query-based input control. This is what we are going to do with the second input control named CITY. Its definition is also a Single Select Queryof type SQL. The query for CITY uses a $X{EQUALS, ..., COUNTRY} parameter in its where condition:

select distinct shipping_address_city from ACCOUNTS  where $X{EQUALS, shipping_address_country, COUNTRY}  order by shipping_address_city[/code]                    

This time the column to be used in the Value and Visible Columns field is shipping_address_city.

When you run the JasperReport, if everything has been correctly configured, the dialog box in “Cascading Input Control Showing Country and Cities” appears. It consists of the two simple input controls, and the CITY control is not populated until the user selects a country.