Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend plugin configuration docs. Fixes #735. Fixes #553 #766

Merged
merged 20 commits into from Nov 16, 2018

Conversation

ST-DDT
Copy link
Member

@ST-DDT ST-DDT commented Sep 11, 2018

Fixes #735
Fixes #553

Tasks

  • Mention TypeTokens which contains already existing type tokens and mention that the user should possibly should use a similar approach if he has multiple type tokens itself.
  • Find out which types have serializers registered by default (any of the above?)
  • Which text serialization format does SpongeAPI use in Configurate by default?
    • Hocon is mentioned multiple times
    • Maybe mention it on the loaders page again
    • Stronger links between config and Text Serializers
  • Which should you use for your plugin?
    • Sponge recommends hocon (Mentioned on the index page)
    • Maybe mention it on the loaders page again
  • How do you override this choice in your plugin for your configurations, or should you use string's and handle serialization yourself?
    • YAML is mentioned, but Gson is not.
    • Needs an example (loaders page)
  • Add a full example of loading and saving a @ConfigSerializable instance to Using Objectmappers.
    • Mention the implications of not using @Setting on a field
    • How to use default values
    • What happens if new values are added/are missing in the config file
  • Expand the example regarding the usage of defaults.
    • How do you actually merge the configs
    • How are/should partial default defaults handled
  • Explain when the config should be saved (for the first time)

TBD

  • Mention recommended way to serialize Texts.

@ST-DDT ST-DDT added the low priority Small issues like typos that don't have much of an impact label Sep 11, 2018
@Spongy
Copy link

Spongy commented Sep 11, 2018

@ST-DDT
Copy link
Member Author

ST-DDT commented Sep 13, 2018

@Simon_Flash mentioned on Discord that there is a different (recommended) way of checking whether the config is empty.

Solution 1A ( suggested )

@Inject @DefaultConfig(sharedRoot = true)
private Path configPath;
@Inject @DefaultConfig(sharedRoot = true)
private ConfigurationLoader<CommentedConfigurationNode> configManager;

if (Files.exists(configPath)) {
	rootNode = this.configManager.load();
} else {
	this.logger.info("No config found - loading default");
	URL jarConfigFile = Sponge.getAssetManager().getAsset("defaultConfig.conf").get().getUrl();
	ConfigurationLoader<CommentedConfigurationNode> defaultLoader =
			HoconConfigurationLoader.builder().setURL(jarConfigFile).build();
	rootNode = defaultLoader.load();
}

Solution 1B ( not tested )

@Inject @DefaultConfig(sharedRoot = true)
private Path configPath;
@Inject @DefaultConfig(sharedRoot = true)
private ConfigurationLoader<CommentedConfigurationNode> configManager;

if (!Files.exists(configPath)) {
    this.logger.info("No config found - loading default");
    Asset jarConfigFile = Sponge.getAssetManager().getAsset("defaultConfig.conf").get();
    jarConfigFile.copyToFile(configPath);
}
rootNode = this.configManager.load();

Solution 2

@Inject @DefaultConfig(sharedRoot = true)
private ConfigurationLoader<CommentedConfigurationNode> configManager;

rootNode = this.configManager.load();
if (!rootNode.hasMapChildren()) {
	this.logger.info("No config found - loading default");
	final URL jarConfigFile = Sponge.getAssetManager().getAsset("defaultConfig.conf").get().getUrl();
	final ConfigurationLoader<CommentedConfigurationNode> defaultLoader =
			HoconConfigurationLoader.builder().setURL(jarConfigFile).build();
	rootNode = defaultLoader.load();
}

I prefer the later variant as

  • it also works with completely empty files
  • it does not need a new injection for only that single usecase
  • it is easier to implement loading the default in case the normal one cannot be loaded due to an IOEx

Which variant should we use in the docs as the recommended way?

@ST-DDT ST-DDT added the input wanted We would like to hear your opinion label Sep 13, 2018
@ST-DDT
Copy link
Member Author

ST-DDT commented Sep 14, 2018

Simon_Flash's reasons for suggesting Solution 1 as stated on discord, just copied here so it does not get lost:

  1. Prefer Files#exists(Path) because that's correct. Just because it works doesn't mean it's correct. When you insert a default config, in my opinion it should only be because the file doesn't exist, not because it's empty. Your hasMapChildren method will not always work.

  2. The AssetManager doesn't return Paths, it returns an Asset. You should copy that asset to the path of the config file if and only if it doesn't exist, then load the config through the path normally. Asset has a variety of copyTo methods for this.

  3. Saving the file to disk will always happen. I find there being more boilerplate to inject things in my opinion.

@ST-DDT ST-DDT changed the title [WIP] Extend plugin configuration docs. Fixes #735 Extend plugin configuration docs. Fixes #735 Sep 15, 2018
@ST-DDT ST-DDT added the needs review The submission is ready and needs to be reviewed label Sep 15, 2018
@ST-DDT
Copy link
Member Author

ST-DDT commented Sep 15, 2018

The main work for this change has been done. So we can start the review period.

There are two things that are up for/need discussion though:

  • First the recommended way of loading a default config from the jar (asset).
  • What is the recommended way of serializing Text: via Config, inline json, extra Json files (per entry?), or via minecraft lang files? Or don't we provide a recommendation until the TextTemplates have been improved?

Copy link
Member

@Inscrutable Inscrutable left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I note you often use "it is recommended". Generally we're allowed to refer to the docs using the "royal we", so it might be better to use "We recommend" in the long run. It takes ownership of such recommendations, and people can always quibble it with a PR if they can demonstrate a better recommendation to adopt.

source/plugin/configuration/loaders.rst Outdated Show resolved Hide resolved
source/plugin/configuration/nodes.rst Outdated Show resolved Hide resolved
source/plugin/configuration/serialization.rst Outdated Show resolved Hide resolved
source/plugin/configuration/serialization.rst Outdated Show resolved Hide resolved
source/plugin/configuration/serialization.rst Outdated Show resolved Hide resolved
source/plugin/configuration/serialization.rst Outdated Show resolved Hide resolved
Copy link
Contributor

@12awsomeman34 12awsomeman34 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really minor stuff.

source/plugin/configuration/loaders.rst Outdated Show resolved Hide resolved
source/plugin/configuration/loaders.rst Outdated Show resolved Hide resolved
source/plugin/configuration/nodes.rst Outdated Show resolved Hide resolved
@ST-DDT ST-DDT changed the title Extend plugin configuration docs. Fixes #735 Extend plugin configuration docs. Fixes #735. Fixes #553 Oct 14, 2018
@ST-DDT
Copy link
Member Author

ST-DDT commented Nov 8, 2018

Some last change requests?

@ST-DDT ST-DDT merged commit fccd598 into stable Nov 16, 2018
@ST-DDT ST-DDT deleted the feature/plugin-config branch November 16, 2018 19:38
@Inscrutable Inscrutable removed the needs review The submission is ready and needs to be reviewed label Nov 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
input wanted We would like to hear your opinion low priority Small issues like typos that don't have much of an impact
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants