Open scattenlaeufer opened 5 years ago
I just had a look and docutils
does have a recent release, nevertheless markdown
does look a lot more lively (or rather, docutils still looks somewhat moribund to me). Since basically the rest of the world has gotten onto the markdown bandwagon, we should maybe ask the question whether we want to support rst at all.
The only feature that missing from markdown, that I can think of from the top of my head, are footnotes, but both markdown
and pandoc, which we will probably want to use to generate PDFs, support them as an extension.
So, might it be time to ditch rst and go all in on markdown?
The only other feature making rst more suitable for us than markdown would be directives for later use when supporting submitting resolutions via git push
, but there is for sure a way around it when using markdown.
We would of course need our own little syntax guide when using the footnotes extension, since that won't be included in the syntax guides found by just googling for one, but that also wouldn't be the end of the word.
So I'll focus on Markdown for now.
Edit: With some extensions markdown
gives us all the functionality we could possibly need, so there is really no need to support two different text formats to create resolutions.
I think all we want to do can be done with markdown extensions, see
Is your feature request related to a problem? Please describe. We want the user to be able to create resolutions in either markdown or reStructuredText, but on for the website we need all text in HTML. So we need a parser to convert the user generated input to HTML.
Describe the solution you'd like I propose to use
docutils
since it can parse both Markdown and reStructuredText. The output frommarkdown
is a bit nicer out of the box, but since it can't parse rST and the output from both inputs should be the same,docutils
seems to be the better solution. Parsing will be done throughcelery
when requesting the HTML version by the view and the result will be cached for future requests. The obvious problem with this approach is the added time, some page requests will get due to the added work load to be done while collecting the view context.Describe alternatives you've considered It would also be possible to parse the text once on creation/modification and store the HTML text in the database, but that isn't the best idea, since it would mean to have the same text in two versions stored in database and might lead ugly problems with mismatched text versions in the future.