PluginConfig

This is an abstract class which is made to make config.yml more easy to use.

Description

The current FileConfiguration system in bukkit uses plain text to access the values. For example, you access the value Plugin.Enabled in config.yml

Plugin:
    Enabled: true

Like this

config.getBoolean("Plugin.Enabled", false);

But one thing I really hated about it is that you have to remember all the names like Plugin.Enable in order to use those values. That's the motivation I got to make PluginConfig class.

If you use PluginConfig class, the PluginConfig class is capable of save the public fields of itself into the config.yml file and vice versa. Now all you need to do is create your public field in your child class extending PluginConfig, and the rest will be handled by PluginConfig.

An Example:

public class MyPluginConfig extends PluginConfig{
    public int My_Config_Value = 1;
}

The benefit of this is that unlike just using get() or set() method of the FileConfiguration, you now have the java field; therefore, you can benefit from the auto-finishing functions of most Java IDEs like Eclipse or IntelliJ as those IDEs will show you the list of available public fields. That's way more convenience than go to config.yml, read name, use get() method, etc.

Though, there are two things to keep in mind.

First, PluginConfig class will replace _ to .(dot) upon saving it into config.yml and vice versa. So whenever you create a public field in your child class, do not leave dangling _ signs.

Good example:

public int Time_Ticks = 20;

Bad examples:

public int _Time_Ticks = 20;
public int Time_Ticks_ = 20;
public int _Time_Ticks_ = 20;
private int Time_Ticks = 20; //even though it doesn't make error, it will not be used as it's not public field.
                             //so technically, it's not a bad example but be cautious about the field accessor.

Second, PluginConfig replace _ to .(dot), so you need to careful about the collision. Depends on how you name the fields, there are some possibility of making collision.

For example:

public int Time = 10;
public int Time_Enabled = true;

In this case, because Time_Enabled will be translate into Time.Enabled, it's now in big trouble. If you think about the .yml file structure, it's something like this:

Time:
    Enabled: true

However, as we can see from the example, we have a 'int' field named Time. So internally, when PluginConfig get the value of 'Time', it will be a ConfigurationSection, not integer. In that case, plugin will fail as ConfigurationSection cannot be cast into 'int'. So be careful when you name the public field.