Enhancement idea: Auto-wiring dataset parameters

[hvbtup]

Think of a report of the sample database with two queries: One query for the Productlines table, a second query for the Products table.
You want to create a catalog-like report which shows some details about a productline, then a table with the correponding products.
While there are different ways to create such a report, one viable way is to use a list item with a grid for the productlines (the grid containing the HTMLDESCRIPTION and the IMAGE columns, usually). For the products, the query should use a WHERE clause like where PRODUCTLINE = ? and a dataset parameter (let's call it param_productline).
So far, so good.
Now create a table inside the detail area of the productlines list, below the grid and bind it to the products dataset.

Now you have to supply the value for the current productline to the products dataset.
To do this, you have to oben the binding tab, click "dataset parameter binding", choose the parameter param_productline, open the expression builder editor by clicking the little fx symbol, choose PRODUCTLINE from the available column binding, double-click to copy this into the expression multi-line edit field, then click OK several times to close all those dialogs.

This is tedious work. Rookies don`t understand what's going on at all, and even experienced BIRT developers sometimes forget this and only notice this when the products output is missing.

This is where my idea of "auto-wiring" comes into play, which would allow beginners to create reports by combining components (building blocks) which experienced developers have prepared.

From the beginner perspective, consider the example from the intro.

In an ideal world, the beginner would see (among others) two building blocks in a library.
They would first drag the building block containing the grid for productlines into their new report.
Next, they would drag the building block for the products table into their report (into the right place).

This should be all that's necessary to create this kind of master-detail report.

The beginner could then customize some styling to the report, but it's not really necessary.

That's the idea.
To achieve this, BIRT would need to be enhanced in several ways, where each of the enhancements should be relatively easy to develop.

The "auto-wiring" is once of the things we need.
Other things which complement this enhancement to reach the goal are

• Loops (a loop is a radically stripped-down list item, which does not generate layout by itself, only its content generates layout).
• Extension Places (named places where sub-structures can be added to a layout structure referenced from a library). Currently, one cannot do this with items referenced from a library: One can change properties and hide things, but one cannot change or add structure.

I'll explain Loops and Extension Places in separate discussions.

Now back to "auto-wiring". Report items in a library are very useful, but using them is not as straightforward as it should be due to the dataset parameter binding which is necessary.

With auto-binding, manually editing the dataset parameter binding would not be necessary most of the times and even if it is necessary, it would be a lot easier.

The basis of auto-wiring the idea of a "plug-shape". Compare this to hardware cables: An USB plug is shaped differently from a HDMI plug. You cannot connect an USB cable to an HDMI socket. You can find the right plug for your cable by just looking at the shape, without thinking about it. That's "auto-wiring".

Instead of the actual shape, we can also use the unique name of the shape to know if a cable fits into a socket.

Now let's transfer this idea to BIRT:
A dataset usually has some dataset parameters for which we need to supply values (at least for one of them, usually).
Now assume that each of these parameters has a "shape name".

The shape name is just a name. It could (for example) be productlines.productline - or more generally, follow a pattern like <entity>.<attribute>. It's important that the shape name is not too generic: A shape name like id or name or description or version doesn't make sense.

Next, assume that each of the bindings also has a shape name.

When we drag and drop a report item (e.g. the products table) into the layout, BIRT should consider the dataset parameters of the dropped item. For each of these DS parameters, consider its shape name. If the shape name is not specified or not unique among the dataset parameters, auto-wiring is not possible for this DS parameter. Otherwise, consider the shape names of the available column bindings (of the current layout context (row[...] and also recursively upwards with row._outer[...]. If there is exactly one binding with the matching shape name, we can auto-wire this (one cable and one matching socket, just plug it in).
If automatic wiring is not possible (more than one "cable" or more than matching one "slot"), we can still use the shape name to restrict the list of candidates in the list of values (column bindings) and to avoid incorrect connections or at least warn about them, ideally directly opening the DS parameter binding dialog.

In our example, we'd have one binding of the shape "productlines.productline" from the productlines binding, and one DS parameter with the same shape name in the DS products, so auto-wiring just works without any user-interaction.

The professional developer who prepares the building blocks would have to specify the shape names of parameters and bindings, however, at least for those bindings which are meant to be used for connection.