Perfion Table Overview

A Table in Perfion is a feature that can hold a table design and a set of queries. The queries produce data that when applied to the design result in a table of formatted information.

Tables are typically setup as selectable, and thus become reusable across the system. When a table is rendered the queries that drive the table design are fed the context of where the table is stored. This means that data from the table’s queries are context sensitive, and so produce context related results.

When tables are included in a report output then a rendering of the table design is performed.

The output of rendered tables is included in the data for internal reporting engine. By binding the table output data to the PerfionTable control a visual representation of the table is available.

The output of rendered tables is available in the InBetween export in the form of Table XML blocks. The Table XML block can contains rows and columns of data as you would expect in a table output.

Simple example

The following is a table design that output Product, Material and Diameter

Open

This design has been run against the products for Category Coffee Makers in the demo database and produces the following output:

Open

Key Concepts

Understanding the data, how it is laid out and how the values interact with each other is vital to understanding table designer.

The key concept with table designer is that data is layout out in Sets. Let’s start with a very simple example, consider the following data:

Looking at the data above the Set of Name is Fred, Jane, Joe & John. The Set of Gender is Female & Male.

TableDesigner will project the set values of a feature in a direction.

Starting with a table design:

As expected this will produce the following result:

The Set values of name were projected downwards. Extending the table design, we might choose Age as the next column, here are the results

Table Designer will intersect the Set of Age (15, 16 & 18) with each of the Name values, and ages that intersect will be projected down alongside the Name.

Starting with Fred, only 16 intersects. Why? Because there is only one Fred who is 16.

Likewise Jane Intersects with 16. Joe, however, Intersects with 15 and 18 and so on.

Notice with Joe, because there are two values that match, space is allocated in the resulting table causing Joe to expand.

Each time you add a column, the set values will be intersected with the value to the left. Another way of saying this is that each columns values are narrowed by the value to the left.

Here is the example data again:

The narrowing effect can work in two directions, both the left and above. Consider the following design:

This design will project the Set of Name down and the Set of Nationality across. The layouts do not reduce each other, so the result is this:

If the design is extended to include Age such:

Then both Name and Nationality will intersected with the Age Set, narrowing the possible results to:

Age is set to project results downwards. The Set of age did not result in more than one result in any of the combinations. If an extra British Jane was added, then you would see Jane expanded and the extra ages in British would be projected downwards.

Examining the results so far, Joe has been condensed into one value because of the way Sets work. Perhaps this is not what the user wants, sometimes it would be more applicable to have a row for each name.

To ensure that there is an entry for each row, it is necessary to include as the first column a Feature that is unique for each item. By adding Identity from the example data into the design then the result is achieved:

The Identity column can be removed from the output by selecting the column then choosing the Always selection on Collapse property for the columns properties. The final result is:

You could further change the design by adding Gender as a grouping above Nationality such:

With this design, the Gender Set is projected first, resulting in Female and Male. Then within Female the Nationality Set is projected, and once again under Male.

The result is:

Setting up Tables

License

The table module is only available under license. If your Perfion client does not have any Table entries under the Features section then it is likely that the module is not available. Create a ticket with Perfion Support if you have purchased the module and the Table features are not present.

Creating a Table feature

To work with tables it is first required that a table Feature is created. This can be created just like any other feature in the Feature section. A Table feature is by default selectable, so that it can be reused.

Adding Table to Configuration

Following the creation of a table, you must decide where best to use it. Would the table be best applied to a categorizer such as Catalog? or would it be best applied directly on a Product.

If you select a left hand side item such as Catalog, then the table can be setup to query data from both the section and its related right hand side items. When referring to left and right hand side items we are denoting to where the data is in the Perfion Client. Left hand side items are typically categorizing types and Products are typically on the right hand side of the client.

By selecting a Catalog (the left hand side) for the table, you can produce a table that cover a lot of products. However, if you wish a finer grained table, then perhaps adding it to the Product (the right hand side) would give the required control.

Tables can be added to a configuration in the same way and any other feature, simply drag and drop it into the configuration.

Before the PriceTable is usable, at least one selectable entry should be established. Select the Feature Data section then navigate to the PriceTable. Next, create a new entry PriceTable entry and name this as you like. The PriceTable entries can’t be designed directly in the Feature Data section, they need to be designed where they are used.

Working with the Table Designer

The table designer editor can be invoked by right clicking on a table value and selecting the Edit Table menu item.

When editing a table that has no queries setup, then the user will be presented with a question about how to setup the Primary query. Don’t worry about answering this incorrectly, it can be changed later.

The question centers on where the Primary query should get its data from. The primary query is the data that is used by default when generating at table. The choice ‘On Items in Current View’ refers to the rows that are available where the table is selected. For example, if the table was selected on a Section, then the primary query would target the Section. If, however, the ‘On Items in Related View’ was selected then the primary query would target the Products.

Read more: