Fix Report Viewer

[nestabentum]

Concerning issue #571 :

I falsely assumed that the submission file name would always have the same index when splitting its path, as this was always the case when I tested the viewer. The submission files in my zip always had the path result/submissions/<submission-file>, therefore I extracted the submission file name from splitting the path at / and accessing index 2.
The submission files in the zip you provided have the path submission/<submission-file> and therefore the filenames are not extracted correctly.

Consequently, I changed the file name extraction to locate the index of the submission folder and find the submission files by a accessing the the found index+1.

Additionally, I changed the way how empty submissions are displayed: Instead of showing one empty line, the text "Empty File" is displayed.

[sebinside]

Thank you for your fast reaction, I will review the PR tomorrow.

[sebinside]

The issue is resolved, thank you. However, the Empty file was not displayed in my tests.

[sebinside]

@nestabentum @tsaglam Also, not related to this issue, but also broken: Didn't an earlier version of the report viewer highlight plagiarized code snippets in the viewer? At least in my tests today, this feature was not visible. Or did I miss something?

[sebinside]

Ah, and I think the lines are also broken here 😅

[nestabentum]

The issue is resolved, thank you. However, the Empty file was not displayed in my tests.

@sebinside Oh, I forgot to push the corresponding commit. It should work now.

[nestabentum]

nestabentum @tsaglam Also, not related to this issue, but also broken: Didn't an earlier version of the report viewer highlight plagiarized code snippets in the viewer? At least in my tests today, this feature was not visible. Or did I miss something?

@sebinside both this issue and the weird looking side panel stem from a bug in the match computation in the report generation. It happens in ComparisonReportMapper#convertMatchToReportMatch. This was last affected by PR #552.

The match computation was dependent on Language#usesIndex which has been replaced by Language#supportsColumns. When the value of the aforementioned methods is true, the match indices are fetched from Token#getIndex, otherwise they are fetched from Token#getLine.
Pretty much all implemented Languages seem to supportColumns and therefore access Token#getIndex which returns -1 (except CharToken). This is the reason for the missing highlighting and -1 being everywhere in the side panel.

I don't really get why a differentiation based on Language#supportsColumns (or formerly Language#usesIndex) is necessary in the first place and why it isn't enough to just use Token#getLine. @tsaglam and @sebinside can you give me a hint concerning this?

[tsaglam]

The match computation was dependent on Language#usesIndex which has been replaced by Language#supportsColumns. When the value of the aforementioned methods is true, the match indices are fetched from Token#getIndex, otherwise they are fetched from Token#getLine.

Pretty much all implemented Languages seem to supportColumns and therefore access Token#getIndex which returns -1 (except CharToken). This is the reason for the missing highlighting and -1 being everywhere in the side panel.

I don't really get why a differentiation based on Language#supportsColumns (or formerly Language#usesIndex) is necessary in the first place and why it isn't enough to just use Token#getLine. @tsaglam and @sebinside can you give me a hint concerning this?

Careful here, basically usesIndex() == !supportsColumns(). If either of those is true, the other one is false. This is why I removed usesIndex. What do these methods mean? Most languages proved line and column indices for a token, meaning in which line in the source code the token is and where in the line. However, some frontends do not. They only provide a continuous index for the code. For example, the character frontend only tells you that the token is the nth character, but has no concept of lines and columns. Historically, the were more frontends like this, but I adapted them to support line and column indices.

What does that mean for you? If the frontend has supportsColumns() == true you use the line and column indices via getLine() and getColumn() (probably just the line index, right?). If it returns false you use the continuous index getIndex().

So change this:

JPlag/jplag/src/main/java/de/jplag/reporting/reportobject/mapper/ComparisonReportMapper.java

Line 36 in 8d28e95

.map(match -> convertMatchToReportMatch(comparison, match, result.getOptions().getLanguage().supportsColumns())).toList();

to !result.getOptions().getLanguage().supportsColumns() (meaning ¬ supportsColumns())

EDIT: As you are confused by the continuous index, it could mean the report viewer does not really support the continuous index and just uses it as a line index? We can check this by using the char frontend and checking if the report displays it correctly (after fixing the line above of course).

[nestabentum]

@tsaglam thanks for the explanation, now I get it. I changed the code accordingly. The ComparisonView should now be back to its old beauty

EDIT: As you are confused by the continuous index, it could mean the report viewer does not really support the continuous index and just uses it as a line index? We can check this by using the char frontend and checking if the report displays it correctly (after fixing the line above of course).

Yes, currently, the report viewer only supports line-wise highlighting.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

[tsaglam]

The ComparisonView should now be back to its old beauty

Great to hear!

Yes, currently, the report viewer only supports line-wise highlighting.

@sebinside we should not address this, we should just remove the char frontend.

[sebinside]

@nestabentum Thank you for the fast work. Really appreciated!
The web viewer works again and in a smaller example, the highlighting was fine. In a large one, the highlighting is still not displayed (although the line numbers are now there). As I currently don't know the origin of this problem, I'll add the problem back into issue #357 and merge this PR for now. Thank you!