Improve speed and maintainability of HTML report implementation

[cruzel89]

Use case As a developer of an HTML report for OFT I want to be able to separate business logic from data presentation so that I can change one of them easily without affecting the other.

Problem with the current solution Currently the generation of the HTML report is completely done inside Java-methods which contain business logic as well as html formatting objects, e.g.

    private void renderComment(final String indentation)
    {
        final String comment = this.item.getItem().getComment();
        if (comment != null && !comment.isEmpty())
        {
            this.stream.print(indentation);
            this.stream.println("    <h6>Comment:</h6>");
            renderMultilineText(indentation, comment);
        }
    }

    private void renderNeeds(final String indentation)
    {
        if ((this.item.getNeedsArtifactTypes() != null
                && !this.item.getNeedsArtifactTypes().isEmpty())
                || (this.item.getUncoveredArtifactTypes() != null
                        && !this.item.getUncoveredArtifactTypes().isEmpty())
                || (this.item.getOverCoveredArtifactTypes() != null
                        && !this.item.getOverCoveredArtifactTypes().isEmpty()))
        {
            this.stream.print(indentation);
            this.stream.print("    <h6>Needs: ");
            this.stream.print(translateArtifactTypeCoverage(this.item));
            this.stream.println("</h6>");
        }
    }

Solution proposal Implementing and maintaining a dynamic HTML page generated by code is much easier when using a template engine. Template engines are designed to achieve a separation between business logic and presentation of data. This enables developers to work on the business logic (here in Java), while the designers can change the presentation without having to dive into the Java business logic.

Possible template engines are for example Pebble or Thymeleaf, but the ideal template engine needs to be analyzed.

[redcatbear]

One of our strict design decisions was and is to not use any other dependencies than the Java standard library. Templates are not part of that (if you don't count parts of JSF - but they are JEE anyway and therefore out of scope).

That is why the implementation looks that way. The only way to get around this would be to implement a minimal template solution with no dependencies in the scope of this project. It is not that hard, but I did not invest time into this.

See also #89. JDynamiTe would be a good inspiration for that.

As for speed: no template solution will ever be that fast. Template scanning and text replacement add a lot of additional overhead, that does not come for free.