dataSetRow[""] vs row[""] usages

[Miurath]

Hello,

I do have a fundamental design question. What is the best practice concerning the default mapping of data when it comes to dataSetRow[""] and row[""]?

Suppose I have a dataset and a table, a grid or a expression in a data element that have access to this dataset.

As I understand it: dataSetRow takes the value from the dataset, row takes it from the binding. If need a value from an outer element I need to use row._outer["abc"] and if I make a custom binding that adds two values (or does something else) I need to use row["abc"].

Let's take a data-element for example:

I could do the expression like this:

if(dataSetRow["abc"] == "Y") 
{
   ...
}

or like this:

if(row["abc"] == "Y") 
{
   ...
}

Both have the same effect. Which one of those is best practice for a simple mapping or for use in an expression? If I do not change the binding of abc in any way, it should always store the same value as the dataset.

The visibility expression doesn't seem to be able to work with dataSetRow, why is that?

Thanks

[speckyspooky]

The standard way to access on scripting level is the usage of row[""].
This option reference to the row object into the background and the current row-object.
So by default you are also able to use the row-accessor also on table level into "dynamic text" or "text"-elements and so on.

The dataSetRow is specific to the "data"-element which is the default object on a table to access the columns of a dataset.
If you drop a colmn to a table column or drop a full table BIRT use "dataSetRow" by default.
But it isn't designed to be used at all script levels.

[hvbtup]

I think what @speckyspooky wrote is not quite correct. AFAIK it's like this:

The standard way to access on scripting level is the usage of row[""].

Yes, this is best practice.

... you are also able to use the row-accessor also on table level into "dynamic text" or "text"-elements and so on.

, e.g. in the output expression itself (dynamic text items), in visibility expressions, in onCreate events, in highlight rules.

If you drop a colmn to a table column or drop a full table BIRT use "dataSetRow" by default.

Actually, when you drag and drop a dataset column or full table into the layout (or into a layout container of the master page), what happens is this:

DnD of a whole dataset:

1. In more recent BIRT releases, the user can choose the dataset columns in a dialog, in older releases all columns are used.
2. BIRT inserts a table item into the layout
3. BIRT binds the table item to the dataset. This also creates a binding entry definition row["COL"] = dataSetRow["COL"] to the table item for each column COL of step 1.
4. For each column COL of step 1, BIRT adds a column to the table item, inserts the column name as a label into the header cell, and inserts a data item (see below) into the detail cell.

DnD of a dataset column COL (not quite sure, but that's my experience):

1. BIRT goes up from the target layout container until it finds a container with a dataset binding; we'll call this BOUND_CONTAINER.
2. BIRT checks if there already is a binding entry definition row["COL"] = dataSetRow["COL"]. If not, it is added to binding entries of BOUND_CONTAINER.
3. It adds the data item itself to the layout. The data item uses row["COL"] internally, although the XML element is called "resultSetColumn":

<resultSetColumn>COL</resultSetColumn>

This works exactly the same for aggregations, the only difference being that when creating the binding entry in step 2, it asks you about the aggregation properties (e.g. which function, which group level) and will alway create a new binding entry.

The only use case for using "dataSetRow" directly anywhere that comes to my mind is as follows:
If the expression for a binding entry COL1 depends on a different column COL2, I usually use dataSetRow["COL2"] in the expression for COL1, just because I don't know in which sequence the binding entries are created; I mean I'm not sure if row["COL2"] is valid at the time when row["COL1"] is defined, but I'm sure dataSetRow["COL2"] is already defined.

BTW I think that inside the event scripts of datasets, row means the current fetched row, so row["COL"] can be used here, too.

[Miurath]

Thanks for the fast replies, this cleared up all my confusion about the topic! 👍

[Miurath]

Sorry for reopening. I did just have some doubts about my understanding of the answers.

Specificly about the paragraph where you talked about the usage of dataSetRow. You suggest to write bindings like this:

if(dataSetRow["a"] == "b")
{
	dataSetRow["c"] + " " + dataSetRow["d"]
}
else
{
	dataSetRow["e"] 
}

But should I still use:

row._outer._outer._outer["f"]

To get to the data binding on an outer element. Ist that correct? I do expect dataSetRow to just go to next outer element that has a dataSet binding and look up the value there. It would never find it, if it were to be located in an element even higher up.

[hvbtup]

You should use dataSetRow only in rare cases like the one you describe in your last comment, and only inside the defining expression of a binding entry. Everywhere else, dataSetRow is undefined.

Accessing row._outer["f"] is only possible in the layout. With _outer, you access the next ancestor with a binding in the layout element tree (this structure is called a sub-report in some other reporting tools).

BIRT hasn't got a data model like other tools.
The data model is implicitly defined by the layout elements with bindings.
Thus, for dataSetRow, there isn't a concept of _outer.

BIRT's way of explicitly binding data sets to layout elements seems a bit complicated at first, but it is the only way to actually reuse data sets from libraries or even in the same report.

[Miurath]

Maybe it's just the reports I work with, but we have if-else and similar things, that check other bindings, everywhere in our reports. We often piece together the blocks of texts that should be printed in data-elements or decide which binding to print, based on the value of multiple bindings.

You say dataSetRow should only be used in rare cases, but isn't everything thats not just "just print dataBinding X"
one of those cases? If something is not just "just print dataBinding X", I have to check the data from other bindings to find out what to print (print X if the bindingY is 2009 and Z if it isn't or something similar).
Checking other bindings should be done, like you said in your comment before, with dataSetRow.

So it is correct to assume, that dataSetRow and row._outer["f"] should be used for all bindings that have a non-trivial value and row["f"] if I just want to map a trivial value or use it in visibility expressions etc.?

[hvbtup]

Regarding row._outer["f"], there isn't a different option to choose. If you need a value from a parent container, then you have to use row._outer.

I don't the distinction between trivial and non-trivial makes sense.
Even if your expression is only based on the original column, it isn't necessarily trivial.
What I tried to explain is that I use dataSetRow if the definition of one column needs the definition of a different column, and row in all other cases, and that it works for me (with > 10 years experience).

Furthermore - but this is a question of taste - quite often I use complex expressions directly inside dynamic text items, and there I use row and I don't need to think about it. But probably definining the expression as an additional "column" in the binding dialog is cleaner.

[speckyspooky]

According to Hennings explanations the standards way is to use the row[]-expression on you scripts.
This is also the method which will provided if you use the wizard of the script builder.
You can do with the row-object all what you need.

[Miurath]

The way I understood his explanation, dataSetRow should be used for if(dataSetRow["COL2"] == "Y") .... constructs in bindings, since I cannot be certain that the row["COL2"] is already defined at that point. Considering this, I should not just use row for referring to another binding of the same element, should I?

[hvbtup]

This is how I do it in my reports. I'm not sure if it's best practice, but I can be sure that it works, so at least it's my personal best practice.
But in most cases I don't perform such calculations in bindings; instead I just compute what I need where I need it. A downside of this is that longer calculations pollute the layout. In such cases, I tend to move the logic into a function which I define in the initialize event (sometimes support row as an argument, sometimes the individual values). So in my reports, complex logic is defined centrally in the initialize event.

[speckyspooky]

I can confirm I use the initialize() method of Javascript functions too. So you have a type of single point of functions.

And I can only repeat the post before to calculate where it is necessary. You can use the row-object as parameter to delegate it to the function.
Another option would be to calculate on SQL level and work there with Cases.