refactor: DSRecordHistory >> #records -> #events (with accessors)

[nicolasp025]

I propose to refactor this as some other classes use the name 'events' for their attributes so it would be uniformed.

[Julesboul]

Why not, but I don't know if there is a reason behind this difference... We should ask Steven before changing this name attribute (cause we can argue for having records also).

In the meantime, is there a need of uniformity between DSRecordHistory, DSWindowRecord and DSWindowActivityRecord?

[nicolasp025]

Yes, I would need them to correspond for a refactoring about the records presenters, the idea would be that every item used for the presenter's roots would define an 'events' method that would return the events, that is already the case for the windows and jumps, and I would like it to be the same for the history.
It could also be 'records' instead, I would just want it to be unified for history, windows and jumps as possible

[Julesboul]

I'm not sure to understand, when do we have multiple histories displayed in your presenter?
I though that there is one history displayed (linked to the selected file).

[nicolasp025]

We have only one history displayed of course, but we have 3 presenters that displays records :

• the records tab (that comes from history)
• the selected window's records in windows tab
• the selected jump's records in the activity tab

The idea would be to generalize a table presenter that displays records and takes a parameter that defines a method that returns the events, which could be 'events' or 'records'