now session$sendInputMessage() does not send options as the choices data, but as a pre-generated raw HTML string; in shiny.js, we just receive this string, and .append() it to the input after the input is emptied
- 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
The 100% width worked well inside of a sidebar, but in other situations
like full-width columns or zero-min-width tables a fixed width is better.
If there's demand we can add parameters for setting the width to custom
values including 100%.
also added a new method shinysession$registerDataObj(), which was designed to be a general data retrieval method: we can store arbitrary data objects as "downloads", and return arbitrary http response based on the filter function; see renderDataTable() and updateSelectizeInput() for two examples
All render functions need to call markRenderFunction on their
return values for this mechanism to work.
Also:
- Remove runRmdContainer (it's moved to rmarkdown)
- Remove some bad .Rbuildignore entries
- Make height/width in shinyApp respected
I always thought dots and colons were illegal in HTML ID attributes,
but I was wrong. They are legal and because they are commonly used
in identifier names in R, Shiny users often like to use them. Worse,
Shiny gave no warnings when using dots and only a pretty advanced
subset of functionality would NOT work when using dots, causing
everyone to think they were fully supported in Shiny.
This commit ought to bring reality in line with perception. It turns
out that jQuery has an escaping scheme in its queries that allow us
to support dots after all. As long as we are always careful to
surround IDs with $escape when putting them in a query, we'll be in
good shape.
Colons will probably still cause problems at the moment because we
use colons internally to separate input type from input name. But
we've never seen users try to use colon in IDs before, so we can
wait to fix it until that becomes a problem.
