LINQ Reporting Engine - All IFs are evaluated, making it impossible to handle NULL values

Assuming the following JSON dataset

{ “value”: null }

And this template which checks for NULL values before making a numerical comparison:

<<if[value != null]>>
<<if[value > 1]>>Greater than 1.<</ if>>
<</ if>>

The template will fail with the following error message:

An error has been encountered at the end of expression ‘value > 1]>’. Can not apply operator ‘>’ to operands of type ‘System.String’ and ‘System.Int32’.

It seems to me that Aspose evaluates all IF expressions and does not consider the fact that the outer IF expression evaluates to false. This makes it impossible to handle nullable numerical values. The expected behavior would be that the inner IF expression is never evaluated because that would be unnecessary in this example.
Thanks.

@p.maier

Before evaluating any expression, LINQ Reporting Engine parses a whole template document. If it finds a syntactic error at this step, it throws an appropriate exception.

In your example, value is a null literal, so the engine is unable to extract its type information from JSON and treats it as String by default. Since a string cannot be compared to an integer, this is a syntactic error, so the exception is thrown as explained previously.

Since there is no way to provide type information for a null literal in JSON, I am afraid that we cannot suggest you something better than the following approach (although we understand that it is inconvenient):

Test("null"); // Prints "Null."
Test("2");    // Prints "Greater than 1."

//-------------------------------------

private static void Test(string value)
{
    string json = "{ \"value\": " + value + " }";
    MemoryStream stream = new MemoryStream(Encoding.UTF8.GetBytes(json));

    JsonDataLoadOptions options = new JsonDataLoadOptions();
    options.SimpleValueParseMode = JsonSimpleValueParseMode.Strict;

    JsonDataSource dataSource = new JsonDataSource(stream, options);

    DocumentBuilder builder = new DocumentBuilder();
    builder.Write("<<if[value != null]>><<if[int.Parse(value.ToString()) > 1]>>Greater than 1.<</if>><<else>>Null.<</if>> ");

    ReportingEngine engine = new ReportingEngine();
    engine.BuildReport(builder.Document, dataSource);

    Console.WriteLine(builder.Document.GetText().Trim());
}

Thank you for the workaround. It is indeed not ideal to use parsing routines in this context. Will Aspose’s interpreter be adapted at some point to tackle this issue? And what time frame could be expected for such a change?
Thanks!

@p.maier

In general, there are two options to support this and similar scenarios:

  1. Support using of JSON schema, so the engine could guess what type it should assign to a null literal. Considering the draft state of the specification, it is unlikely that we will follow this path in the near future.

  2. Support using of dynamic objects as data sources, so the engine would check operand types by the time of expression evaluation rather than parsing. This requirement is already logged as WORDSNET-12148. Unfortunately, due to its complexity, it is postponed and there is no ETA available at the moment.

We will also further investigate whether we can deliver support for your specific case sooner without making major changes to the engine. This is logged as WORDSNET-23833. We will notify you through the forum thread, once we have any progress on it.

@p.maier

It is to inform you that we have found a way to support your original scenario without making major changes to the engine, that is, WORDSNET-23833 is resolved now and will be included to Aspose.Words for .NET 22.9. You will be notified through the forum thread once it is available.

Starting from Aspose.Words for .NET 22.9, JSON null values will be treated as null literals when JsonSimpleValueParseMode.Strict is applied as follows:

JsonDataLoadOptions options = new JsonDataLoadOptions();
options.SimpleValueParseMode = JsonSimpleValueParseMode.Strict;
JsonDataSource dataSource = new JsonDataSource(..., options);

The issues you have found earlier (filed as WORDSNET-23833) have been fixed in this Aspose.Words for .NET 22.9 update also available on NuGet.