Revamp content display API

[benwoo1110]

improve based on @dumptruckman comments

content display API changes

• Decoupled the parsing of map/list vs displaying of inline/paged into ContentParser and SendHandler. Less complex and easier to manage.
• Decoupled the sending away from ContentDisplay. Now it's in its own SendHandler class. ContentDisplay is only responsible for storing and invoking ContentParser and SendHandler class.
• Remove the messy settings stuff. Now it's just setter methods in the respective handler classes.
• Remove the use of ColorAlternator, it was very retrictive.

Other additions

• Added filter for gamerules command.

[dumptruckman]

Some notes for now. I'll have to look again later. Heading to bed.

[dumptruckman]

I think that this might be more readable as a separate class. It could just be a private static one in this class maybe?

[benwoo1110]

yea can change that. Probably use a singleton instance?

[benwoo1110]

hmm dont really want do use static class so I don't have to pass in the plugin instance to the private class, so current just doing something like private class WorldListContentParser implements ContentParser { and then .addContentParser(new WorldListContentParser());

[dumptruckman]

What's wrong with passing the plugin instance into the new class's constructor?

[benwoo1110]

tbh nothing wrong, but then I can't really use a singleton instance anyways, as not a good idea to store plugin objects in static like this right? Like if a new instance plugin instance is created, it may cause issues? So I just decided to make it inner class nonstatic so it uses the instance from the parent class.

[dumptruckman]

I think this might be better if it returns the content list instead of is given one to add to. I think this is just a gut feeling and maybe isn't entirely right but I feel like a list you're given to modify smells a bit more than just returning a list.

[benwoo1110]

The reason why this doesn't just return a list of strings so we only need one common list. Instead of each parsing creating a new list as then adding it to another common list... which is potentially is a lot of lists.

For whether if we delete/modify existing entries from other parsers, either we allow it as a feature, or just instead pass a wrapper around the List that only allow adding of elements.

But all these won't be needed if we decide to only allow one content parser.

[dumptruckman]

First glance, this seems like it could easily be a single method, functional interface. If the need to filter is false, then the checkMatch should just return true. In that case, you could also just use the built in Predicate interface.

[benwoo1110]

Yea, then reason I d have the second method, is so that there is no need to loop through the content to filter is there nothing to filter. And when displaying to user, it output whether or not filter was applied to the content.

[benwoo1110]

Example use cases:

// Only send output of filter string used if needed.
if (filter.needToFilter()) {
    sender.sendMessage(String.format("%s[Filter '%s']", ChatColor.GRAY, filter));
}

// Only loop to filter if needed, to save performance
if (filter.needToFilter()) {
    return content.stream().filter(filter::checkMatch).collect(Collectors.toList());
}
return content;

[benwoo1110]

implemented in #2824