Error or failure information can be collapsed

[hailin-xiao]

Hi,

Could you please add a new feature that user could collapse the error or failure log? it's a little bit hard to find the useful information once there're hundreds of errors or failures in the report.
For better understanding, I would like to give an example:

balabala

Thanks very much and looking forward for that.

Regards,

Hailin

[davidedelvento]

@davehunt - I think this becomes even more important because of #44 (at least for some people).
I'll be happy to work on a rudimentary javascript implementation and make a PR, if no one is working on it already.

[hailin-xiao]

@davidedelvento @davehunt
Thanks for your quick response. Actually, we have made a temporary solution to satisfy our project. It's to make some changes on main.js. Please refer to the changes listed below. Any comments are appreciated. Thanks

Hailin

[davehunt]

Interesting, so this hides all log content by default and allows users to show the logs by clicking anywhere in the row? For my use case I prefer the log to be displayed by default, though I agree with @davidedelvento that I might prefer logs from passing tests to be hidden. Perhaps we could have a 'display log' link for these, and a 'hide log' link for any logs displayed?

We could also have 'show all logs' and 'hide all logs' links at the top of the page if users want to quickly toggle all logs. It then also sounds like we should have a preference for controlling if the logs are displayed initially, unless the 'hide all logs' does what we need there?

[hailin-xiao]

@davehunt Thanks for your reply. It's just a temporary workaround for this as we don't have enough time to do this. I definitely agree with your solution. It could be great for user to choose display or hide the logs. But it would be better to let each log have such an option. We're looking forward to the solution be committed. Thanks a log.

Hailin

[RibeiroAna]

Hi @davidedelvento, I just did a piece of code on the PR #46 that may help you when working on that issue, the first main change is that I've put an ID on the "extra html" div and I did some JS (without using JQuery or any other library) that gets all the logs, maybe it is a good start point for you. My code was not merged yet, but I hope it will be soon, right @davehunt ?

[davidedelvento]

Hi @RibeiroAna that sounds good, having that ID will be helpful. I'll give it a try, hopefully tomorrow. Thanks.

[davidedelvento]

I've finally found some time to look at this (note that I'm not a javascript/html expert, so I plan to use very naive approach and a better one may be possible: suggestions welcome).

First, the ID that @RibeiroAna is using is not helpful for me, because it's in a separate html.td tag. My idea was to add to the html.td containing the log something like id="1" (with different number for each test), to hide the whole line with the captured out/err. Note the discrepancy between my use of the word "line" and the fact that this data is in a html.td container.

My problem is that the relevant html.td is placed into a separate <tr class="extra"> by javascript (so <tr class="extra"> does not exist into the generated report file), so I could hide the td but not the whole tr as I wanted.

@davehunt Would it be ok to change the existing javascript to pull extra stuff (e.g. id="1") from <td class="extra"> to the containing <tr class="extra">? Or is that thing going away anyway for #29 and we should instead migrate to having a separate row anyway (which will be much easier for me to do)?

[davehunt]

I have no objections to any changes that do not regress the current functionality. Issue #29 will make sure the report is presented and functional when JavaScript is disallowed, but that doesn't mean that we can't have additional functionality when JavaScript is allowed. Note that id should be unique, and perhaps you'll be able to do what you need with data attributes instead?

[davidedelvento]

The fact that id should be unique is not a big deal, since you want each click on a results-table-row hide/show the relevant extra row for that row and not for something else.

The problem I have at the moment is that split_extra_onto_two_rows() generates two extra rows instead of only one as I expected looking at the browser, and therefore two identical ids. Inspecting the generated HTML, the first extra row is empty and not displayed, while the other has the actual content.

I am not sure why this happens, and here is where I am stuck at the moment. Other than that, I've got this functionality working (if test_id is unique, otherwise I need also to make it unique in some additional way, no big deal).

See my fork for a clearer explanation (sometimes code is clearer than words...)

[davehunt]

The row split is being removed as part of the outcome filtering. Hopefully this will make your work a little easier when it lands.

Dave Hunt

On 3 Jun 2016, at 23:33, Davide notifications@github.com wrote:

The fact that id should be unique is not a big deal, since you want each click on a results-table-row hide/show the relevant extra row for that row and not for something else.

The problem I have at the moment is that split_extra_onto_two_rows() generates two extra rows instead of only one as I expected looking at the browser. Inspecting the generated HTML, the first extra row is empty and not displayed, while the other with the actual content.

I am not sure why this happens, and here is where I am stuck at the moment. Other than that, I've got this functionality working (if test_id is unique, otherwise I need to make it unique in some additional way).

See my fork for a clearer explanation (sometimes code is clearer than words...)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[davidedelvento]

Yes I saw that work in progress, but I wanted to give collapsing a first shot against the current release. As a workaround, I can use data attributes as you say (instead of IDs) and my current code should work.

Is the row split removal imminent, or is there still a fair amount of work needed? On one hand, I don't want to add a functionality which will need to be rewritten as part of that removal, making it harder. On the other hand, if the removal is taking time and this functionality is ready, why wait?

[davehunt]

I think it will be ready by the end of this week.

On 4 Jun 2016, at 12:41, Davide notifications@github.com wrote:

Yes I saw that work in progress, but I wanted to give collapsing a first shot against the current release. As a workaround, I can use data attributes as you say (instead of IDs) and my current code should work.

Is the row split removal imminent, or is there still a fair amount of work needed? On one hand, I don't want to add a functionality which will need to be rewritten as part of that removal, making it harder. On the other hand, if the removal is taking time and this functionality is ready, why wait?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[leitzler]

@davehunt any new eta? ;)

[davehunt]

The row split code was removed in 1.9.0, which should make this easier to implement. I am not currently working on this though - perhaps @davidedelvento is still interested?

[davidedelvento]

Yes, I am very interested and I plan to work on this.