FasterXML / FasterXML/jackson-dataformats-text

More configurable TOML serialization

Abierto
#254 11 comentarios 8 reacciones 0 asignados Ver en GitHub
TOML
Lenguaje dominante
Java
Estrellas
455
Forks
164
Merge medio
6 d 10 h
PR fusionados (30 d)
2

Descripción

Right now, the toml serializer generates only top level properties, and inline tables where necessary (i.e. where arrays are used):

```toml
abc.foo = 1
abc.bar = 2
abc.xyz = [{foo = 1, bar = 2}]
```

There are special cases where we *could* generate normal toml tables. The example above can be expressed as:

```toml
[abc]
foo = 1
bar = 2

[[abc.xyz]]
foo = 1
bar = 2
```

This format will in many cases be more readable. However, there are problems with non-inline tables that prevent us from emitting them in a streaming generator:

- Once a table is started, it is impossible to go back to the parent or root table. If an object has scalar properties that we only see after we started a subtable, we have a problem.
- Array tables only work with arrays of objects. If an array is heterogeneous, but we've already started emitting it as an array table, we have a problem.

These problems can only be solved with knowledge of the tree being serialized, and perhaps even by influencing property order so that scalars always come first. However, because I expect serialization to toml to be fairly niche – it is a configuration format meant to be written by humans, after all – it is not worth adding machinery to databind to implement this.

Another question to consider: What even *is* the best representation of an object? A short inline object may be more readable than starting a new table that includes the entire path to that object.

A possible solution to this problem would be to add API to the TomlGenerator to specifically start a table. One approach would be to create overloads for `writeStartObject` and `writeStartArray` that allow forcing generation as a table. If data is then passed that cannot be represented as a table (the bullet points above), we would error. While we're at it, could also allow emitting comments with additional methods.

We could also inspect annotations on the `forValue` passed to `writeStartObject`, though this seems like misuse of that parameter, so not a good idea.

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.