We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Reporting/LINQ bug in loading of JSON, assumes string before accessing

When loading a json file that contains a null field, the interpreter chooses a string type which may not always be correct.

For instance in the following situation:

JSON:
{
“Name”: “Some Name”,
“ob”:
{
“nest”: null,
“stringVal”: “asasdfdf”,
“intv”: 45
}
}


Document :

<<if[ob.nest?.value]>>

Test: <<[ob.stringVal]>>

<>


The json data source makes the assumption that the null value of the nested value must be a string.
Then when the reporting engine tries to evaluate the line <<if[ob.nest?.value]>> it does not stop when it cannot find the value for nest…

Instead we get the error:
System.InvalidOperationException: ‘An error has been encountered at the end of expression ‘ob.nest?.value]>’. Can not get the value of member ‘value’ on type ‘System.String’.’

If we enable missing member though we still have an issue since the reporting engine now cannot evaluate the if statement:
The following error is produced: System.InvalidOperationException: ‘Tag ‘if’ is not well-formed. A conditional expression should return a Boolean value.’

To try and mintage this the ?? could be used except that the reporting engine has a blank object instead of null and does not know how to evaluate it now.

Document:
<<if[ob.nest?.value ?? false]>>

THIS IS TEXT

<<[ob.stringVal]>>

<>

Gives the following error:
System.InvalidOperationException: ‘An error has been encountered at the end of expression ‘ob.nest?.value??false]>’. Can not apply operator ‘??’ to operands of type ‘System.Object’ and ‘System.Boolean’.’

Attached solution:
BrokenJsonLoading.zip (1.7 KB)

To get each error please modify the files for the given situation

What would be the timeline on the fix for this situation, as we consider this a critical bug?

@nross

We have logged this problem in our issue tracking system as WORDSNET-21108 . You will be notified via this forum thread once this issue is resolved.

We apologize for your inconvenience.

Hi @tahir.manzoor
This is a critical bug for us, is there any update on it?
The biggest issue is that the Null conditional (?.) operator is not working as intended here. It should not be trying to access past the point of null. See Microsoft Doc

Your own documentation says that this is a supported feature here unless I am mistaken.

The whole issue is that right now we have to place empty data in the data to ensure that all paths can be me. Instead if the null conditional operator was working this would not be required and would greatly improve stability of the templates.

@nross

We try our best to deal with every customer request in a timely fashion, we unfortunately cannot guarantee a delivery date to every customer issue. We work on issues on a first come, first served basis. We feel this is the fairest and most appropriate way to satisfy the needs of the majority of our customers.

Currently, your issue is pending for analysis and is in the queue. Once we complete the analysis of your issue, we will then be able to provide you an estimate.

@tahir.manzoor
Please understand that this bug basically with break all our “fixed” templates since they will be the correct data type. For instance <<if[item == false]>> right now needs to be <<if[item==“false”]>> since the json data source is ignoring all types. When this bug gets fixed we will need to correct a lot of statements. This is not a good situation. Additionally as I mentioned before it seems to have broken the Null conditional (?.) operator at the same time. These bugs may not be related but both are causing huge issues with the LINQ generation.

@nross

Thanks for sharing the more detail about this issue. We have logged this detail in our issue tracking system. We will be sure to inform you via this forum thread once there is an update available on this issue.

@nross

It is to inform you that the issue which you are facing is actually not a bug in Aspose.Words. So, we have closed this issue (WORDSNET-21108) as ‘Not a Bug’.

This is an expected behavior. Since the value of nest is set to null in JSON, the engine cannot “guess” the type of nest as well as which fields it has, if any. The engine uses type String by default in such cases.

Since field value is missing in the provided JSON object but is used in the template, ReportBuildOptions.AllowMissingMembers should be applied.

When ReportBuildOptions.AllowMissingMembers is applied, the engine treats a missing member as a null literal as per API Reference. That is, <<if [ob.nest?.value]>> is equivalent to <<if [null]>> in this case. But an if tag requires an expression returning a Boolean value as specified in the note at Template Syntax and in the text of the exception gotten by you.

The simplest way to fix the broken tag is as follows: <<if [ob.nest?.value == true]>> . In case when nest is null and value is missing in JSON, it acts like <<if [null == true]>> , which is equivalent to <<if [false]>> . Moreover, it acts as <<if [true]>> when the value of nest is defined within JSON as follows:

"nest": { "value" : true }. Please check the attached TestNestedQuestionmarks-Modified.docx template. TestNestedQuestionmarks-Modified.zip (10.7 KB)

@nross

This is a related issue with template syntax. Since ob.nest?.value is treated as a null literal by the engine in this case, <<if [ob.nest?.value ?? false]>> is equivalent to <<if [null ?? false]>>. If syntax null ?? false is used directly in C#, a compile-time error appears. A similar error is generated by the engine, so this is not a bug either. LINQ Reporting Engine tries to be as close to C# as possible, hence the behavior.

The simplest way to fix the broken tag is as follows: <<if[(bool?)ob.nest?.value ?? false]>> . The same way as it would be done in pure C# for a null literal. Check the attached TestNestedQuestionmarks2-Modified.docx template. TestNestedQuestionmarks2-Modified.zip (10.8 KB)

Field value is missing in JSON, so the engine treats the whole expression referencing the field as a null literal when ReportBuildOptions.AllowMissingMembers is applied as explained earlier. So the expression is never evaluated, hence the issue has nothing to do with the null-conditional operator.

Please use the template syntax as per the attached modified templates. Everything should work as expected and no further changes will be required.