An answer to both of these issues is the use of R code. It should be possible to drive shiny apps through the server, without the user's code knowing the difference. And you've already thought of recording user actions as R code. This would be an application of the command pattern, as with undo/redo stacks, except each object boils down to a function/expression (Tengfei and I have a CRAN package called commandr related to this). Someone should try to make a prototype to explore these issues then we can start thinking about common infrastructure.
On Fri, Jul 26, 2013 at 12:23 PM, Dan Tenenbaum <dtene...@fhcrc.org> wrote: > Hi everyone, > > There was a lot of talk about shiny at BioC2013 and it seems like a > lot of people are using it for lots of different cool stuff. > > Now we are at the point where some contributors want to add shiny apps > to Bioconductor as packages. > > We had some discussion internally and decided that there are a few > issues we wanted to discuss with BioC developers as well as some of > the shiny developers. Please feel free to share your thoughts. > > 1) Testing shiny apps > > Typically, bioconductor packages have man page examples, vignettes, > and (sometimes) unit tests, so when we build the packages every day on > our build system, the code in all of these is evaluated and we have > some idea of whether the package is working as it's supposed to. > > I'm not clear on how to do similar testing of a shiny application. > Since launching a shiny app takes away the R console (until the app is > closed), shiny apps should probably not be launched in example or test > code (unless interactive() is TRUE). > > Do the shiny folks (or anyone else) have thoughts on testing shiny apps? > > 2) Reproducible research > > Reproducible research is really important in our community, but shiny > apps are sort of a black box as far as reproducibility is concerned. > > If shiny apps are "read-only" (that is, if they are just used to view > an object) then this is not really a problem. But shiny has the > ability now to change objects back in your R session, so we need to be > able to track what is done inside the shiny app. > > shiny apps can return some sort of object that tells you what was done > in the shiny session (insofar as it modifies any objects in the > users's session) and this object can provide a way to reproduce those > steps without the shiny app. So maybe the object would consist of > lines of code. This means that if there is a shiny app, the package > author must also provide ways to do the same transformations on > objects without shiny. > > There are probably other approaches as well. But the end goal would be > a scriptable, reproducible shiny session. > > Another thought was that a shiny app could emit some sort of state > object, and then be restarted with that object. > > Not sure if the place for such infrastructure is inside shiny itself, > or perhaps in a BioC infrastructure package. > > What are your thoughts? > Dan > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
