[Code] Placement of parsing and writing logic

[tobiasdiez]

Right now parsing and serialization is not handled in a uniform way. (see e.g #875)

Possible designs which come to my mind:

• The BibParser and BibWriter contain all the logic as private methods.
  • e.g.: BibParser.parseMetaData(String stringyMetadata) and BibWriter.writeMetaData(Metadata)
  • pro: encapsulation of responsibilities
  • contra: rather big classes BibParser and BibWriter, hard to test
• There are transformer classes which just convert the string to the object and vice-versa.
  • e.g.: MetadataTransformer with static parse(String stringyMetadata) and static write(Metadata) [suggestions for a better name then transformer? ReadWriter?]
  • pro: encapsulation of responsibilities (but weaker as 1), can be reused somewhere else, better testability
  • contra: exposes writing and parsing to the outside world, many new classes
• The corresponding objects have methods which allow parsing and converting to string.
  • e.g.: Metadata has static parse(String stringyMetadata) [or constructor?] and serialize()
  • pro: encapsulation of responsibilities (but weaker as 1 and 2), can be reused somewhere else, better testability as 1
  • contra: exposes writing and parsing to the outside world, scatters parsing and writing logic

I have no strong opinion about which option we should use (slightly preferring 2), but we should decide for one to handle parsing and writing uniformly.

[simonharrer]

My 2 cents: For the file field, we provided a class that can convert from String to List and back.

To me, the BibWriter and BibParser know how to write bibentries using key/value pairs of strings, and metadata in its general format.

All other information should be part of such converter classes.

But I am not sure, whether this approach is currently feasible for the metadata as its serialization and parsing is highly customized and does not follow a general scheme as the bibtex structure does.

[lenhard]

I have been dealing with the serialization of MetaData a lot lately. I can say that it is feasible to extract this logic. Currently, it is quite localized in private methods in the parser and writer and we should be able to move it without too much effort. The difficult part about serializing MetaData is that every tag has very specific serialization conventions which requires a lot of if/elseif structuring. Moreover, I don't think this will require a lot of new classes. After all, for what kind of data do we need such transformers? MetaData, CustomEntryType, what else?

The parser and writer would benefit from a simplifaction, so I am for moving this logic.