Feature/entry sections

[Mwexim]

Entry sections are sections that require a specific set of entries to act as some sort of configuration.

Skript's command syntax is the perfect example.

command /test:
    usage: &cUsage: /test
    permission: plugin.test
    permission message: &cYou lack the permission to do that.
    trigger:
        # Do stuff

We can immediately see the key features of the new SectionConfiguration.

• Optional and required 'option' entries that store a string value (like the permission or usage).
• Sections that store an entire CodeSection inside (like the trigger entry).

The SectionConfiguration class essentially makes the creation of these configuration sections easy, handling all possibilities, error messages and more.

This pull request is not completed yet as I still feel like some refinements should be made.

[ItsTheSky]

OwO Thank you a lot for adding this that fast! It seems to work as same as for the olds one, so it will be easier to use. However, could you maybe provide a way to directly parse input using the section ? Lemme explain:

Imagine we have this code:

define website:
    port: 5030
    trigger:
        # </>

Instead of getting the port value directly, and then parsing it from our side, why not add a Function in the addEntry() method, for example:

new SectionConfiguration()
        .addOption("port", false, input -> {
            // input is a String
            /*
             We could return an optional here:
             - If the optional is empty, then an error occurred and SectionConfiguration will return false
             - Else, it will attribute the parsed optional to this entry key and will return it when using getOption()
            */
            try {
                return Optional.of(Integer.parseInt(input));
            } catch (Exception ex) {
                logger.error("Invalid integer input: " + input);
                return Optional.empty();
            }
        });

[Olyno]

.addOption("port", false, input -> {
    return Integer.parseInt(input);
});

This should be better. Optionals are important but only skript-parser should deal with it mainly. When getting options, we simply return a Optional of the option's value.

[Mwexim]

While the latest commit does not add the proposed feature directly, it makes it possible to do so. I will push the last commit soon, which will add the proposed feature and make it even easier to handle.

Furthermore, I need to add Javadoc, a better explanation of what I'm doing and overall code improvements. The code is still somewhat all over the place but I'm way happier with what I created now than the old system. It's way more advanced than Skript's currently and allows developers to easily extend on the current system, which already provides many tools.

I'm currently not really asking for a review, I will do that when I'm done with the last changes.

[WeeskyBDW]

@Mwexim any news about that PR ?

[Mwexim]

@Mwexim any news about that PR ?

This is almost ready to be merged honestly. Just a quick sweep/refactoring is necessary to make it more user-friendly, as well as some Javadocs explaining how everything works.

[TheLimeGlass]

I think returning an Optional for getValue could be nice, as the entries may not be present, rather than null.

Also a cool feature would be allowing a pattern to be placed in the add entry methods, to allow for a pattern to be used to parse the key. like (executor|command sender) to allow for either executor: or command sender:

[Mwexim]

So I refactored a lot of code, resulting in breaking changes. I'm sorry to do this abruptly but I just couldn't stand the old implementation. If you are just implementing this, the changes will be minimal as only some methods have changed. I also added a lot of Javadoc and more descriptive error messages to further help future developers along.