On Wed, Mar 29, 2017, at 11:23 AM, Martin Morgan wrote:
> On 03/29/2017 09:32 AM, Vladimir Kiselev wrote:
> > Hi Wellinton,
> >
> > As far as I know if you wrap you shiny stuff into an R function that should
> > be enough. Then you can provide both non-interactive and interactive
> > functions and the user can choose what to run.
> >
>
> - Allow for interactive use integrated in an R session -- during an R
> session, the app is used for particularly graphically-oriented
> operations, and the end result of app usage is made available to the R
> session for subsequent processing. This kind of workflow, not
> necessarily in shiny, is possible in epivisr and RCyjs;
> interactiveDisplay was developed with this idea in mind
This is what I have done in flowPloidy:
https://github.com/Bioconductor-mirror/flowPloidy
The user passes a list of FlowHist objects (an extension of flowFrame)
to the shiny app. Within the app they can correct the model fitting.
After exiting the app, the updated objects are returned for further work
at the R console.
Shiny uses some non-standard evaluation techniques (I think that's the
right description?) that make it a little tricky to keep track of the
appropriate environments when updating objects. I posted a short toy
example to stack overflow that shows how I dealt with that:
http://stackoverflow.com/questions/17263627/shiny-r-application-that-allows-users-to-modify-data/38835957#38835957
This requires using the `<<-` operator to pass a value up one level of
nesting within the app function. It doesn't directly modify the global
environment though, so should be acceptable. I can't figure out any
other way to deal with this.
I started out providing functions to complete the entire process from
the command line. But the shiny interface is so much more convenient and
powerful that I rarely use the command line functions anymore, even for
debugging.
Best,
Tyler
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
