- Need to carefully review ShinySession, think about
each and every public method and whether it should
be passthrough or do something different for a
namespaced session.
- It would be nice if we do the namespace splitting
at the server.R level and actually have numerous
reactivevalues objects for inputs, one for each
namespace. This will make the reactive hooks for
names() and reactiveValuesToList() correct, as
right now they will oversubscribe if you're in a
namespaced session. Also it would prevent outer
sessions from seeing the values of their child
namespaces. (Though is that good or bad...?)
This reverts commits deffc90, ab4dc64, and 0755579, returning to RJSONIO.
The purpose of this is to prepare for a maintenance release for 0.11
without the switch to jsonlite, to reduce the risk of new bugs.
After discussing with @trestletech, the semantics are just not right.
When using it with a renderXXX function, it doesn't actually stop
recomputation, so the only reasonable place to use it is in a reactive
expression, but if that's true then this is a terrible looking API.
Will replace soon with something better.
This reverts commit 8d4b9076f7.
The main concern for the previous reversion was the Glimmer/Spark servers (Rcpp requires R >= 3.0.0). We are able to install Rcpp/httpuv under R 2.15.3 (https://gist.github.com/yihui/43a68d811dade1d9e828), so it is possible to upgrade Rcpp/httpuv/shiny on Glimmer/Spark. On the other hand, we are going to shut down Glimmer/Spark by the end of this year anyway, and move to ShinyApps.io, which makes this R 3.x issue even less of concern.
This reverts commit e4239c924b.
I totally forgot the problems this causes with R 2.15 and thus
glimmer/spark. httpuv 1.2.2 requires Rcpp 0.11 which requires
R 3.0. So existing installs (like glimmer/spark) that are
running just fine with httpuv 1.2.0 will be forced to upgrade,
which is hard to do when you don't know the provenance of
all the packages installed by your users.
These functions were temporarily ripped out of Shiny and moved
to the htmltools package. We've discovered that it's safe to
keep including them in shiny; as long as the functions in shiny
and the functions in htmltools are identical, the user won't
receive a conflict warning.
we can call shiny:::setServerInfo() in Shiny Server before launching an app, so that the app author can make use of the info to decide the behavior of the app
- validateInput renamed to validate
- validateCondition renamed to need
- Removed ability to provide "bare" conditions. It is
still possible to fail validation silently by passing
FALSE as the second argument to need()
- Rather than using a two-element list to convey results,
use a single result protocol; NULL is success, FALSE is
silent failure, string is failure with message
- Tweak "missing input" semantics, add tests
