enable access to metadata within knit environment

[jjallaire]

It would be useful in the code in the Rmd document could easily access
the variables in the yaml metadata. Maybe bind to rmarkdown (or
metadata?) in the global environment when the code is knit?

Then you could do things like:

---
title: my title

---

```{r}
plot(1:10, main = metadata$title)
```

I can imagine this might be a useful way of parameterising reports so
you only need to change something in one place.

[jjallaire]

We could also add a metadata parameter to the call to render. This would be a list that is merged with the metadata in the document (sort of like command line parameters overriding config file options). What's cool about this is that you could then write an R function on top of render that is basically just a shim to calling render with arbitrary parameters.

[hadley]

You could also use it as a report generation tool - i.e. make user_id a template parameter and then call render multiple times substituting in different values of user_id.

[jjallaire]

Yes, that's the whole idea!

On Fri, Mar 28, 2014 at 12:48 PM, Hadley Wickham
notifications@github.comwrote:

You could also use it as a report generation tool - i.e. make user_id a
template parameter and then call render multiple times substituting in
different values of user_id.

Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-38941265
.

[Thell]

Sweet! This is a nice idea!

If filter was a metadata tag

    ----
    title: my title
    output:
      html_document:
        filter: foo::bar()
    ----

Handled similar to how citeproc is in pandoc.R.

 args <- c(args, "--filter", pandoc_citeproc())

Then render("file.Rmd", output_format = "all") could work with it too.

[jjallaire]

How about if we put a bit more explicit structure around this capability. We could create a special object name (e.g. params) and publish the contents of it to the page,e tc.

---
title: my title
params:
  foo: bar
  data: deafult_data.csv
---

Those would be made available as a "params" object within the knit environment. The render function could then be extended to take a params which would override the YAML. Users could then build functions on top of this to instantiate paramaterized reports, etc. e.g.

my_report <- function(data) {
   render("my_report.Rmd", params = list(data = data))
}

We'd of course lose the ability to access all the metadata but using an explicit construct like "params" might make the feature more comprehensible. We could of course also expose "metadata" with everything to have the best of both worlds.

[hadley]

Most of the blogging engines allow access to both I think. Might also be nice to allow access to site metadata from output.yaml. But maybe that's already covered by the metadata merging strategy.

I'm not sure making params explicit makes things simpler: then if you want to vary the title, you'd need to use a different syntax.

(Also I just remembered I need to tell you about modifyList in base r)

[jjallaire]

I see that, my big concern is being able to articulate and use the feature without the conceptual baggage of referring to parameters/variables as "metadata". Of course jekyll, et al just populate the entire Liquid variable scope with the contents of the metadata so you can just say "$title$". We clearly wouldn't want to do that with the R environment so it's got to be one of:

metadata$title

variables$title

params$title

I think that the second two forms read much nicer but overlay another concept over what's literally just metadata so perhaps not worth it? Let me know if you think we can/should go with one of these forms or just stick with metadata.

[hadley]

What about page$title? Or file$title? I agree that metadata might be un-obvious. Otherwise I think params is my favourite option so far.

[jjallaire]

Okay, I think I'll go with params

[jjallaire]

Resolved via 7731784

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.