all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* capture htmlwidgets for export - a pattern in search of a new :results type???
@ 2015-07-28 19:29 Cook, Malcolm
  2015-07-28 21:34 ` Charles C. Berry
  0 siblings, 1 reply; 3+ messages in thread
From: Cook, Malcolm @ 2015-07-28 19:29 UTC (permalink / raw)
  To: emacs-orgmode@gnu.org

I have been playing with exporting htmlwidgets [1] generated in R code-blocks.

[1] http://www.htmlwidgets.org/  and

Here is a worked example that exports to html

	#+BEGIN_SRC R :session *R* :exports both :results html 
	library(htmlwidgets)
	library(d3heatmap)
	widget<-d3heatmap(mtcars, scale="column", colors="Blues")
	saveWidget(widget,'d3heatmap_widget.html')
	print('<iframe height=700px width=700px src=./d3heatmap_widget.html></iframe>')
	#+END_SRC
	#+RESULTS:
	#+BEGIN_HTML
	<iframe height=700px width=700px src=./d3heatmap_widget.html></iframe>
	#+END_HTML

After doing a few of these, a pattern emerges:  using ':results html' in the code bock header, and the last 2 lines of:
	saveWidget(...)
	print('<iframe ... ')

I think this pattern motivates considering developing support for "htmlwidget" as a new :results type (in addition to 'raw, org, html, latex, code, pp, drawer') 

It could be used in combination with :file and understood by the R/org "glue" and exporters.

Allowing to write, instead of the above, something like:

	#+BEGIN_SRC R :session *R* :exports both :file d3heatmap_widget.html :results htmlwidget :height 700 :width 700
	library(htmlwidgets)
	library(d3heatmap)
	d3heatmap(mtcars, scale="column", colors="Blues")
	#+END_SRC
	#+RESULTS:
	file: d3heatmap_widget.html

The org-to-R glue would have to behave somewhat similarly to how graphics are currently handled, however, instead of "printing" the value to the :file, the value would need to be saveWidget-ed.

And, similar to image handling, the exported value would be "in-lined" into the html, wrapped in an iframe (I presume).

Perhaps there is  a better or more useful abstraction.

Or a better workaround than simply following the pattern when needed (which is not too hard anyway).

Any ideas along these lines?

Thanks

Malcolm Cook
mec@stowers.org

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: capture htmlwidgets for export - a pattern in search of a new :results type???
  2015-07-28 19:29 capture htmlwidgets for export - a pattern in search of a new :results type??? Cook, Malcolm
@ 2015-07-28 21:34 ` Charles C. Berry
  2015-07-29  0:08   ` Cook, Malcolm
  0 siblings, 1 reply; 3+ messages in thread
From: Charles C. Berry @ 2015-07-28 21:34 UTC (permalink / raw)
  To: Cook, Malcolm; +Cc: emacs-orgmode@gnu.org

On Tue, 28 Jul 2015, Cook, Malcolm wrote:

> I have been playing with exporting htmlwidgets [1] generated in R code-blocks.
>

[snip: proposal for new :results format to accomodate repetitive codes]


>
> Perhaps there is  a better or more useful abstraction.
>
> Or a better workaround than simply following the pattern when needed (which is not too hard anyway).
>
> Any ideas along these lines?

See

 	(info "(org) Noweb reference syntax")

for one way to handle repetitive codes.

Alternately, header args :var, :post, :prologue and/or :epilogue could be 
used to crystallize your code.

One other alternative is to write an R function that creates the extra 
markup.

HTH,

Chuck

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: capture htmlwidgets for export - a pattern in search of a new :results type???
  2015-07-28 21:34 ` Charles C. Berry
@ 2015-07-29  0:08   ` Cook, Malcolm
  0 siblings, 0 replies; 3+ messages in thread
From: Cook, Malcolm @ 2015-07-29  0:08 UTC (permalink / raw)
  To: 'Charles C. Berry'; +Cc: emacs-orgmode@gnu.org

> On Tue, 28 Jul 2015, Cook, Malcolm wrote:
> 
> > I have been playing with exporting htmlwidgets [1] generated in R code-
> blocks.
> >
> 
> [snip: proposal for new :results format to accomodate repetitive codes]
> 
> 
> >
> > Perhaps there is  a better or more useful abstraction.
> >
> > Or a better workaround than simply following the pattern when needed
> (which is not too hard anyway).
> >
> > Any ideas along these lines?
> 
> See
> 
>  	(info "(org) Noweb reference syntax")
> 
> for one way to handle repetitive codes.
> 
> Alternately, header args :var, :post, :prologue and/or :epilogue could be used
> to crystallize your code.

Excellent!  Glad to be directed to these.  The combination of all of them gets me over the fence:

#+name: iframe
#+begin_src sh :var it="" :var height="700px" :var width="700px" :results output :exports none
       printf "<iframe src=%s height=%s width=%s >" $it $height $width
#+end_src

#+header: :prologue {file="d3heatmap_widget.html"; saveWidget({
#+header: :epilogue },file) ;file}
#+BEGIN_SRC R :session *R* :results html :exports both :post iframe(it=*this*,height="800px" width="800px")
library(htmlwidgets)
library(d3heatmap)
d3heatmap(mtcars, scale="column", colors="Greens")
#+END_SRC

#+RESULTS:
#+BEGIN_HTML
<iframe src=d3heatmap_widget.html height=800px width=700px >
#+END_HTML


I don't really care for all the verbosity of the header, but the effect is perfect.  The code block does not contain ANY extra org-mode export-specific cruft.

TH,

Malcolm

> 
> One other alternative is to write an R function that creates the extra markup.
> 
> HTH,
> 
> Chuck

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-07-29  0:08 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-07-28 19:29 capture htmlwidgets for export - a pattern in search of a new :results type??? Cook, Malcolm
2015-07-28 21:34 ` Charles C. Berry
2015-07-29  0:08   ` Cook, Malcolm

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.