ituob / ituob.github.io

Searchable ITU OB web view, generated from itu-ob-data
2 stars 2 forks source link

Update freeform issue contents rendering: switch from including AsciiDoc files to ProseMirror structures #3

Open strogonoff opened 5 years ago

strogonoff commented 5 years ago

It’s better if only structured representation is stored, so that rendering of such structure into HTML & other deliverables is handled by site build.

Unfortunately, full render instruction may be somewhat tricky since we support complex nested contents such as tables. As plan B, we could render it to HTML during editing from the ITU OB editor app and supply that alongside structured contents, so that (at least temporarily) we don’t have to deal with rendering this at site build stage.

Sample amendment specifying freeform contents:

  - type: amendment
    target:
      publication: E118_IIN
      position_on: 2018-12-01
    contents:
      type: doc
      content:
        - type: paragraph
          content:
            - type: text
              text: foo
            - type: text
              marks:
                - type: em
              text: bar
ronaldtse commented 5 years ago

AsciiDoc (including tables) could technically be parsed into a deterministic structured format.

Writing text like this will be very painful...

    contents:
      type: doc
      content:
        - type: paragraph
          content:
            - type: text
              text: foo
            - type: text
              marks:
                - type: em
              text: bar
strogonoff commented 5 years ago

AsciiDoc (including tables) could technically be parsed into a deterministic structured format.

Writing text like this will be very painful...

    contents:
      type: doc
      content:
        - type: paragraph
          content:
            - type: text
              text: foo
            - type: text
              marks:
                - type: em
              text: bar

@ronaldtse I just noticed your comment. You prefer that we store, in the repository (note that it’s not visible to site visitors, they’ll see rendered content), text editor data in a more “human-authorable” way than YAML structured this way?

ronaldtse commented 5 years ago

@strogonoff I'd rather we store AsciiDoc in YAML in the repository. For example, it's easy to transform between:

    contents:
      type: doc
      content:
        - type: paragraph
          content:
            - type: text
              text: foo
            - type: text
              marks:
                - type: em
              text: bar

and

foo _bar_