make widgets also available as a web asset

[timelyportfolio]

If htmlwidgets is as successful as I think it will be, a separate package for each widget will get quite unwieldy. Maybe think about each widget as both an R package or web-available structure (gh-pages branch), so that a separate install is not required. I think htmlwidgets really is the only thing that absolutely needs to be a package.

Think about all the install_github issues we have had with rCharts and slidify and this very quickly becomes nightmarish. If we could get htmlwidgets on CRAN, and it should be simple since it is so targeted, then things become much easier if there is only one package install.

[timelyportfolio]

So I made some changes in my fork with this commit. While I do not think this is the ideal way to handle, I think something like this is much better.

devtools::install_github("timelyportfolio/htmlwidgets")
require(htmlwidgets)

Then this source the R code and the assets are defined as web resources instead of local files. The really ugly part of this is the source which could do ugly/mean things, but without a central repository to reconcile widget to location of function, I do not know how else to handle.

source('http://timelyportfolio.github.io/htmlwidgets_spin/R/spin.R')
spin()

I guess we could in theory do both with master being the package and gh-pages being the online version.

[timelyportfolio]

I think the decision on this is to require an R package to make a widget which will copy the appropriate dependencies into a local directory. While I still would love to see htmlwidgets that don't require an install, I think that is outside of the scope of this project and no longer applicable, so going to close :)

[ramnathv]

For what it is worth, with minimal tweaks, I was able to make widgets work in a non-package setting. The idea is for widgets to be contained in a folder that follows some conventions.

widget
|- htmlwidgets
|- widget.js
|- widget.yaml

In the createWidget call, one would then refer to the path to the widget, and from there on everything works seamlessly.

[timelyportfolio]

That would be very nice, but thinking more in the context of cdn for widgets where say a gh-pages branch can serve up a widget, so nothing needs to be stored or copied locally. I'm sure you could make it happen but also know we'll run into pandoc issues here and violate the multi-context principle.