Role of root table in JsonDataProvider

Hello,

We are using a JsonDataProvider as a DataSource for ListLabel.

A simplified version of its json input:

{
  "Cost": [
    {
      "Name": "C01",
      "Amount": "200"
    }
  ],
  "Expense": [
    {
      "Text": "E01",
      "Amount": "1000"
    }
  ]
}

This will show the two types under the root table “Table” of the json data provider.

And it will use this structure when adding the table to report container:

It’s clear that the JsonDataProvider always creates a root table. What’s not clear yet, is the reason why this root table was introduced for this provider.

In our case the ‘Cost’ and ‘Expense’ types are independent and would be good to have them both at root level. For that the idea was to use a custom data provider. But to not implement everything from scratch, it would wrap a JsonDataProvider.

public class JsonDataProviderWrapper : IDataProvider
{

    private List<ITable> _tables = new List<ITable>();

    public JsonDataProviderWrapper(JsonDataProvider jsonDataProvider)
    {
        // use tables of json data provider, except the root table
        _tables = jsonDataProvider.Tables
            .Where(t => !string.Equals(t.TableName, jsonDataProvider.RootTableName, StringComparison.OrdinalIgnoreCase))
            .ToList();
    }

    // this is needed to be able to show more types at root level
    public bool SupportsAnyBaseTable => true;

    public ReadOnlyCollection<ITable>? Tables => new ReadOnlyCollection<ITable>(_tables);

    // relations from JsonDataProvider are not reused because there is no relation between the types in our use case
    public ReadOnlyCollection<ITableRelation>? Relations => new ReadOnlyCollection<ITableRelation>(new List<ITableRelation>());

    public ITableRelation? GetRelation(string relationName)
    {
        return null;
    }

    public ITable? GetTable(string tableName)
    {
        return _tables.FirstOrDefault(t => string.Equals(t.TableName, tableName, StringComparison.OrdinalIgnoreCase));
    }
}

Which gives the result:

But could this break any functionality of the designer or cause any issue for exporting?
Would you suggest to use this solution or is it more adviced to keep the root table?
Why was the root table concept originally introduced for the JsonDataProvider?
We would like to choose the solution which works best in long term.

Thanks in advance.

Hello Andras,

welcome to the LL forum!

You can do it that way. The root level is necessary because there could also be flat properties.

As it is currently structured, all sub-relationships are unavailable, so if further tables were to appear below “Cost” or “Expense,” it would not work with the provider. But if the data structure is fixed as shown, there is no reason not to use that solution.

Regards,
Chris

1 Like