Export multiple-line string in YAML block notation

gamerover98 commented 8 months ago

What I'm trying to do

I'm attempting to include a JSON schema in a YAML property. Here's an example:

json: |
  {
    "age": 30,
    "city": "Rome",
    "email": "john.doe@example.com"
  }

The issue

While ConfigMe reads this property correctly, it saves the config file with the JSON schema replaced by a string:

json: "{\n  \"age\": 30,\n  \"city\": \"Rome\",\n  \"email\": \"john.doe@example.com\"\   \n}\n"

What I'm expected

I expect ConfigMe to load the JSON schema without replacing it with a string.

My test code

@Test
void test() throws IOException {
    // given
    Path configFile = TestUtils.copyFileFromResources("/config/example_json_property.yml", temporaryFolder);
    PropertyResource resource = new YamlFileResource(configFile);

    Property<String> jsonProperty = PropertyInitializer.newProperty("json", "");
    ConfigurationData configurationData = createConfiguration(singletonList(jsonProperty));
    configurationData.initializeValues(resource.createReader());

    // when
    resource.exportProperties(configurationData);

    // then
    String json = jsonProperty.determineValue(resource.createReader()).getValue();
    Person person = JsonUtil.parseConfig(json, Person.class);
    ...
}

Perhaps we should create and use a JsonProperty class instead of a StringProperty class.

gamerover98 commented 8 months ago

In addition, JSON schemas are a valid substitute for Beans. For example, with JSON, we have many more options compared to beans:

Data Structure Flexibility: JSON allows greater flexibility in defining data structures compared to Java Beans. You can represent complex and nested objects without having to create corresponding Java classes.
Data Exchange Across Languages: JSON is a universal, language-independent data format. Serializing to JSON allows data exchange between applications written in different programming languages.
Readability and Debugging Ease: Data serialized in JSON format is human-readable and easily interpretable by both humans and machines. This can simplify debugging and code maintenance.
Wide Support: JSON is widely supported in many programming languages and has serialization/deserialization libraries (such as GSON, Jackson, etc.) that streamline the process.
Integration with Web Technologies: JSON is extensively used in web services and data interchange within web applications. Its adoption facilitates integration with web technologies like JavaScript, easing communication between the client and server sides.
Natural Handling of Dynamic Data Types: JSON naturally handles dynamic data types, making it suitable for situations where the data structure may vary.

This list was generated using ChatGPT 🥇

ljacqu commented 8 months ago

I don't really understand your point. Your starting configuration is the same value as what ConfigMe ends up exporting, just written in different formats. In YAML, the following are exactly the same values:

json: |
  {
    "age": 30,
    "city": "Rome",
    "email": "john.doe@example.com"
  }

json: "{\n  \"age\": 30,\n  \"city\": \"Rome\",\n  \"email\": \"john.doe@example.com\"\   \n}\n"

Both YAML blocks will be read the same way by ConfigMe. We could come up with a way to define how string should be exported, as separate property type or as an option on StringProperty, which I'm sure would be useful for a wide array of applications. As for JSON-specific things, I don't think it makes much sense to have features out of the box in ConfigMe to mix JSON into YAML.

gamerover98 commented 8 months ago

I don't really understand your point.

I'm sorry, I'll clarify. What I'm trying to say is that when you load the configuration that uses the pipe |, ConfigMe compacts the multiple-lines string into one by replacing the newline with \n, resulting in something like the following: json: "{\n \"age\"...

Both YAML blocks will be read the same way by ConfigMe

That's true, but the second one is not very readable.

We could come up with a way to define how string should be exported, as separate property type or as an option on StringProperty, which I'm sure would be useful for a wide array of applications.

Do you mean that we could decide whether to compress the string or keep the line breaks in the config? Perhaps we can check if the string property starts with the Literal Block Style | or the Folded Block Style > followed by a newline \n.

I don't think it makes much sense to have features out of the box in ConfigMe to mix JSON into YAML.

No problem, I expected a response like that, but I still hoped for it 😄 Anyway, if we resolve this issue, we can manage the multiple strings as we want. For example the content of a Minecraft book and not necessarily a JSON or any type of multiple-line script.

In any case, I guess we can retitle this issue as "Multiple-line string not supported" or something like that.

AuthMe / ConfigMe