Old header -> YAML header converter
Closed this issue · 6 comments
In order to make transition from old syntax to YAML (new) one less painful, it'll be kewl to write a helper that takes template with old syntax and converts it... you get the rest. @daroczig I reckon you'll like the idea, just drop a few more lines to tell me what do you think about it. Suggestions are welcome, and I'll also take no, you're crazy, don't f***in' do it!!! as an answer. =)
Of course we need it.
About YAML, pls check out this: vubiostat/r-yaml#4
But I am also thinking about an own R helper to generate the yaml (we need to support only lists, which is a piece of cake).
Let us chat about this in the near future.
I was in the mood to code some new writer (like pander
), please see the above referenced commit. Of course this is a really basic yaml
writer, but AFAIK we do not require a more robust model ATM. As there are no "UTF-8" issue with yaml::yaml.load
, we can use that as a parser. And if the Unicode
issue would be resolved, we can even drop my basic writer and use as.yaml
as we intended to do - or dropping my quick writer even before that :)
Okay, awaiting feedback. Quick demo:
> cat(toYAML(tpl.info('example')))
meta:
title: Example template
author: Gergely Daróczi
desc: This template demonstrates the basic features of rapport. We all hope you will like it!
email: ~
packages: []
dataRequired: TRUE
example:
- rapport("example", ius2008, v='age')
- rapport("example", ius2008, v='gender', pacman=FALSE)
- rapport("example", ius2008, v='age', s='FOO BAR')
inputs:
- name: v
label: Variable
type: variable
limit:
min: 1
max: 1
default: ~
mandatory: TRUE
desc: A variable
- name: pacman
label: Pacman
type: boolean
limit:
min: 1
max: 1
default: TRUE
mandatory: FALSE
desc: Show Pacman in the results?
- name: s
label: A string
type: string
limit:
min: 0
max: 256
default: Bye!
mandatory: FALSE
desc: Any character value to be printed at the end of theriport
So based on this commit I'm getting a strange feeling that you want to ditch yaml
package.
Just as I wrote above: we needed something like my custom solution until that Unicode issue is not resolved in yaml
package, but I would not want to write a yaml parser too, so I definitely vote on using yaml
package - just as before.
Okay, then pushing the changes I made. Will use your code (and BTW thanks for the effort).