📝File types

Since 1.0.0

Since the very first version of MCUtils, any class that extends the FileHolder interface can be registered to any MCPlugin. On this page, we will see every file-related interface that comes with MCUtils, starting from the most basic one.

FileHolder

The FileHolder interface is the most basic one, and as such, it only requires three pretty much expected methods to be implemented. For this one, an example is better than any amount of words.

import net.codersky.mcutils.files.FileHolder;

public class CustomFile implements FileHolder {

    @Override
    public boolean create() {
        // Code required to create the file or files handled by this FileHolder.
    }

    @Override
    public boolean reload() {
        // Code required to load the contents of the file, as files should be cached.
    }

    @Override
    public boolean save() {
        // Code required to save the file (Write cached and possibly modified data)
    }
}

And that's it. You are not even required to return the File that your FileHolder should, well, hold. This is because FileHolders are allowed to hold multiple files. For example, on my network, a LangManager exists that actually holds multiple files, one per language supported by the plugin. Now, back to MCUtils. We still have two more interfaces left.

FileUpdater

Only for FileHolders that can be updated to newer versions, such as the PluginFile.

import net.codersky.mcutils.files.FileUpdater;

public class CustomFile implements FileUpdater {

    // FileUpdater extends FileHolder, so all methods from FileHolder and...

    @Override
    public boolean update(@Nullable List<String> ignored) {
        // Code required to update the file or files to the latest version.
        // An example can be seen on PluginFile
    }
}

MessagesFileHolder

Now, this one is a bit more tricky. It extends the FileHolder interface, not the FileUpdater one, so you can implement both FileUpdater and MessagesFileHolder if you really want to do so.

import net.codersky.mcutils.files.MessagesFileHolder;

public class CustomMsgFile implements MessagesFileHolder {

    // FileUpdater extends FileHolder, so all methods from FileHolder and...

    @Override
    @Nullable
    public String getString(@Nonnull String path) {
        // Get a String from the file by path, as YmlFile does.
    }

    public List<String> getStringList(@Nonnull String path) {
        // Same as the String getter, but for lists of strings.
    }
}

But that's not all! Each of those two methods have two more defaults with Replacer support, so getString(String, Replacer) and getString(String, Object...) are also provided, same for the string list getter. There are also message senders included for CommandSenders, these defaults work by path and automatically detect if you are trying to send a list of messages to the sender or just a single message. Here is how the CustomMsgFile class would be used.

import net.codersky.coolplugin.files.CustomMsgFile;

public class TestMsgFile {
    
    private final CustomMsgFile file; // Assume we have an instance of it...
    
    // Lets assume the String under "example.path" is "This is a %test%".
    
    public void sendToPlayer(@Nonnull Player player) {
        Replacer testReplacer = new Replacer("%test%", "test string");
        // The getter string will be initialized to "this is a test string"
        String getter = file.getString("example.path", rep);
        // This will send "This is a test" to the player.
        file.send(player, "example.path", "%test%", "test");
    }    
}

We strongly recommend you to check and read the documentation of every default method from this class, really. They are useful, but also have probably unexpected behavior if you only read their name and assume how they work, such as ignoring empty messages to avoid sending blank messages to players. By the way, for yaml files the MessagesFile already exists, have you checked that one?