Question: Nested bean serialization (Example: Minecraft chat)

[games647]

Minecraft chat uses JSON. This allows advanced chat formatting like specifying hover and click events. I'm trying to build the same thing in YAML to make use of comments and migration services.

Example YAML. (Valid YAML according to Online-Parser):

message-key:
  color: blue
  text: outside
  bold: true
  extra:
    - color: green
      text: inner1
      italic: true
    - color: blue
      text: inner2

But if I try to save it with the Bean example. It builds something like this below.

Output

message-key:
    color: 'green'
    extra: 
    - !!ChatComponent
    color: yellow
    extra: null
    text: inner
    text: 'outside'

Bean:

public class ChatComponent {

    private String color;
    private String text;
    private List<ChatComponent> extra;

//setters and getters
...
}

Settings class

    public static final Property<Component> TEST =
        newBeanProperty(ChatComponent.class, "message-key", initComponent());

    private static ChatComponent initComponent() {
        ChatComponent comp = new ChatComponent();
        comp("green");
        comp("outside");

        List<Component> extras = new ArrayList<>();

        ChatComponent extra = new ChatComponent();
        extra.setColor("yellow");
        extra.setText("inner");
        extras.add(extra);

        comp.setExtras(extras);
        return comp;
    }

[ljacqu]

Probably the combination of bean type with collection isn't supported. I'll cook up a test case and will try to implement it. :)

[ljacqu]

Initial analysis: as assumed, support for collections isn't great. The entire "extra" field is not split further and exported as SnakeYAML does by default. And that is exactly this:

    - !!ChatComponent
    color: yellow
    extra: null
    text: inner

which explains the weird output and the wrong indentation. So what I need to do is be aware of the collection type and generically decide whether it needs to be visited further, or if it's OK to export the entries directly (e.g. for string list).

[ljacqu]

@games647 Do you need this urgently? I can probably figure out some ugly hack to do it for now but I want to revise how the entire export process is happening (#52). The current architecture is just a workaround for a workaround built on top of a hack :P

[games647]

Do you need this urgently?

No not really. I have a lot of other things which I can work on ;)

[ljacqu]

This works a lot better since the refactoring, though I've found some weird behavior in the export of Optional properties.

[ljacqu]

I close this now seeing as some complicated test cases pass with the new structure of ConfigMe. Please share a sample if there is still an issue and I'll look into fixing it.