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.
- 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
This warning was happening to dependent packages on R CMD check.
The problem is due to delayedAssign; it appears this can't be used safely, at least not to define package-level symbols that contain S4 or reference class objects.
If you call this in a package's .R file:
`delayedAssign("hello", stop("boom"))`
but don't refer to "hello" anywhere, when you run R CMD check on a dependent package you'll see the error.
If the expression needs the methods package (like Context$new()), you'll get an error unless the dependent package itself depends on methods.
Ref:
https://groups.google.com/d/msg/shiny-discuss/cgSHsM1FCjY/vgU1-jmkGjkJ
The user reported that on a page with multiple uiOutputs whose corresponding
renderUI calls all returned sliderInputs (but no sliderInput was present in
ui.R), some but not all of the sliders were initialized correctly; the ones
that were not didn't receive the jquery-slider treatment and just looked like
text boxes.
This was caused by a fundamental flaw in our handling of singletons in
renderUI. The implicit assumption in the old renderUI code was that:
1) Any HTML we generate in renderUI would be rendered in the client
2) Given multiple calls to renderUI, the HTML we return will be rendered in
the client in the order that we generated it
Both assumptions are incorrect. #1 would be incorrect in cases where an output
is rendered twice before flushOutput is called (this is possible when using an
observer to modify a reactive input, for example), and #2 is incorrect when
output is flushed with multiple values (very common, and exactly what was
happening to the user scenario linked above).
This commit fixes the problem by deferring singleton-handling for uiOutput to
the client. We don't assume that a singleton has been rendered until right
before we render it. The implementation uses a surroundSingletons function on
the server side to surround all singletons with <!--SHINY.SINGLETON[sig]-->
and <!--/SHINY.SINGLETON[sig]-->, which will then be parsed and removed in
the htmlOutputBinding in shiny.js. (And because singletons may contain <head>
elements, we also need to defer <head> hoisting to htmlOutputBinding as well.)
The context$filter mechanism previously used in tagWrite was not flexible
enough to handle this kind of singleton processing. The new rewriteTags
function does tag walking and rewriting much more robustly and flexibly than
context$filter, so I also refactored renderTags to use it instead.
One unrelated problem I noticed was that singleton only worked reliably on
tags, possibly on characters and definitely not on list() or tagList(). This
is because list flattening was happening at tag construction time, which
can cause singleton objects to be trampled. (Among other reasons, such as
context$filter not being called on list objects.) I changed tags.R to not do
any flattening or NULL dropping at tag construction time, but instead to do
it at the last minute during tagWrite.
This bug was introduced in 3fc1410. Essentially it boils down to the difference between stringifying a factor, and stringifying a list containing a factor:
> as.character(factor('a'))
[1] "a"
> as.character(list(factor('a')))
[1] "1"
The call to split that was introduced in this commit ends up generating lists of factors, not vectors of them.
The best fix I could find was to convert all the attribute values to character before doing the split.
