CGMES. Add functional logs

[zamarrenolm]

Signed-off-by: Luma [email protected]

Please check if the PR fulfills these requirements (please use '[x]' to check the checkboxes, or submit the PR and then click the checkboxes)

• [X] The commit message follows our guidelines
• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

Does this PR already have an issue describing the problem ? If so, link to this issue using '#XXX' and skip the rest Closes issue #1887.

[sonarqubecloud[bot]]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

34.9% Coverage
0.0% Duplication

[sonarqubecloud[bot]]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

64.4% Coverage
0.0% Duplication

[sonarqubecloud[bot]]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

63.3% Coverage
0.0% Duplication

[zamarrenolm]

There's been a misunderstanding here, the reporter goal is missed out. The functional logs should contain typed values, to format them according to user standards (for instance we could think of precision of displayed value depending on its type, color displayed, link to the voltage level diagram if vl id, ...). It's also meant to be used for multilingual support, and should thus be easily translated based on the user language.

Here so far the logs are preformatted using String.format("xxx %d %f %s", x, y, z) and the keys are equal to the log string: reporter.report(item, item). Hence the front end cannot do anything more with the log than printing them, and multilingual support is impossible.

A good way to expose those problems is to export the test case in json and look at the dictionary.

Your are completely right in your observations. This PR was a first effort to adapt the information about issues found during the conversion to the reporter API without making almost any change to the current code.

[miovd]

There's been a misunderstanding here, the reporter goal is missed out. The functional logs should contain typed values, to format them according to user standards (for instance we could think of precision of displayed value depending on its type, color displayed, link to the voltage level diagram if vl id, ...). It's also meant to be used for multilingual support, and should thus be easily translated based on the user language. Here so far the logs are preformatted using String.format("xxx %d %f %s", x, y, z) and the keys are equal to the log string: reporter.report(item, item). Hence the front end cannot do anything more with the log than printing them, and multilingual support is impossible. A good way to expose those problems is to export the test case in json and look at the dictionary.

Your are completely right in your observations. This PR was a first effort to adapt the information about issues found during the conversion to the reporter API without making almost any change to the current code.

I would prefer if you start with few logs in the reporter but correctly built to be usable by an external application! Maybe you can start with the invalid messages for example.

[zamarrenolm]

There's been a misunderstanding here, the reporter goal is missed out. The functional logs should contain typed values, to format them according to user standards (for instance we could think of precision of displayed value depending on its type, color displayed, link to the voltage level diagram if vl id, ...). It's also meant to be used for multilingual support, and should thus be easily translated based on the user language. Here so far the logs are preformatted using String.format("xxx %d %f %s", x, y, z) and the keys are equal to the log string: reporter.report(item, item). Hence the front end cannot do anything more with the log than printing them, and multilingual support is impossible. A good way to expose those problems is to export the test case in json and look at the dictionary.

Your are completely right in your observations. This PR was a first effort to adapt the information about issues found during the conversion to the reporter API without making almost any change to the current code.

I would prefer if you start with few logs in the reporter but correctly built to be usable by an external application! Maybe you can start with the invalid messages for example.

Sure, I will refactor the change to follow that.

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

80.3% Coverage
0.0% Duplication