Add a utility method to get table rows as Collection

[freva]

Add a utility method to get table rows as Collection

[sibiarunachalam]

These two utility methods are required

1. public static <T> List<String> getTableRows(Character[] borderChars, Collection<T> objects, List<ColumnData<T>> columns)
2. public static List<String> getTableRows(Character[] borderChars, Column[] rawColumns, Object[][] data)

[sibiarunachalam]

Hi @freva , could you review my PR #11 ?

[freva]

@sibiarunachalam Not sure how much utility these methods provide when you can achieve the same effect in 1 line by creating the table normally and then splitting the result by new line? E.g.:

String table = AsciiTable.getTable(planets, Arrays.asList(
        new Column().with(planet -> Integer.toString(planet.num)),
        new Column().header("Name").with(planet -> planet.name),
        new Column().header("Diameter").with(planet -> String.format(Locale.US, "%.03f", planet.diameter)),
        new Column().header("Mass").with(planet -> String.format(Locale.US, "%.02f", planet.mass)),
        new Column().header("Atmosphere").maxColumnWidth(8).with(planet -> planet.atmosphere)));

List<String> rows = Stream.of(table.split(System.lineSeparator())).collect(Collectors.toList());

Or just Java 11:

List<String> rows = List.of(table.split(System.lineSeparator()));

[sibiarunachalam]

Yes, @freva this workaround will solve the problem.
But, my points to have utility methods:

1. In my case, I split the table into rows for some additional processing and merge them again as table. This util methods will remove these two steps (reverse processing) split and merge.
2. Theses two steps are unnecessary overheads in Ascii Table construction especially when few hundred thousands of records involved
3. It may cause problem when the data has line/row separator
4. Other issue #9 need not be addressed immediately, but that would be nice to have feature.
5. Library provides options to the developers (shouldn't enforce them to implement in one way that they consider as not good practice for many reasons)
6. Even I am not sure about how much utility it provides, but ease of use.

Let say if we had those utility method, which approach would you prefer in my scenario?

[freva]

Since ASCII tables is inherently for humans and not machines, I don't think/hope anyone would use this for anything more than a thousand rows, which makes any performance issue coming from the reverse processing negligible.

The library supports linebreaks in the data, feel free to try the split on this example: https://github.com/freva/ascii-table/blob/d19f522aaccd4a0e057f9843b7d722957c595559/src/test/java/com/github/freva/asciitable/AsciiTableTest.java#L320:L363

To make a utility method worthwhile, it should either solve a non-trivial problem or solve a frequent problem to the users. In my opinion, the solution/workaround is trivial, so it's not that. And I'm not convinced this is a frequent problem, how often would someone need to post-process something a table, specifically on row level? Maybe if this output all the cells, without borders, I could see it, because then the developers could actually customize a lot. With pure rows (including borders), all you can do is join it back together, or filter/insert some rows.

[sibiarunachalam]

Okay @freva, thanks for your feedback.