5 Replies Latest reply on Jul 25, 2013 11:38 AM by jesper.pedersen

    TTALE-213 redux


      IMHO, TTALE-213 uncovers a broader problem with HTML generation in Tattletale: not only writeHtmlHead() (which is the source of broken HTML) is duplicated in every report extending NestableReport but also writeHtmlBodyHeader() is cut-and-pasted in every report class.

      This calls for some refactoring, which I made an attempt at in my GitHub clone (unfortunately, combined with other changes, but I would gladly extract the specific changes).


      Yet another issue is hardcoded links to (typically) archive reports (in the form of "../jar/...") - they do not work when nested archives are analyzed. I think I have solved that, too. Anyone willing to review?

        • 1. Re: TTALE-213 redux

          One PR per change is best.


          Ideally it shouldn't even be HTML generation, but XML with a possible transformation afterwards.


          The hardcoded links are likely an issue too - separate PR for that one too if possible.

          • 2. Re: TTALE-213 redux

            XML generation looks nice on paper, but the problem is that HTML reports are all linked in a hierarchy.

            How easy would it be to extend that hierarchy with an XML schema?

            • 3. Re: TTALE-213 redux

              The default transformation should be a transformation that would output the current HTML. Step 1 is to separate the data and the output representation. Then both can be improved independantly.

              • 4. Re: TTALE-213 redux

                Showing my ignorance: just learned about XLink ... could that be a possible way to XMLisation?


                Anyway, going back to the original topic: refactoring of HTML generation can help, IMHO.

                How many PRs do you need: one for a specific refactoring, like writeHtmlHead(), writeHtmlBodyHeaders(), join(), etc?

                In the end, I even used an override of toString() in ArchiveType enum which in turn affects Main, core and profiles

                • 5. Re: TTALE-213 redux

                  Keep the PRs small - focusing on one specific area - you can do multiple refactoring in one PR, but they have to be related. When in doubt it is better to split.


                  My time is limited, so it is easier for me to merge small PRs with a clear and precise JIRA than larger ones which has multiple unrelated changes.