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
- shinyUI and shinyServer calls are no longer required in ui.R and server.R
- shinyAppObj renamed to shinyApp
- runApp can take pathname, list(ui=..., server=...), shinyApp, and shinyAppDir
as appDir argument
- Unify all Shiny app representations around shiny.appobj
- BREAKING CHANGE: shinyUI no longer has a "path" argument
- Instead of returning UI, ui.R can return a function that returns UI; it will
be invoked each time the page is requested. (Note that this is NOT the same
as saying ui.R will be run each time the page is requested.) The function can
take either no args or a single "req" arg which is the request.
This refactor changes the level of abstraction where sub-apps are implemented.
Sub-apps can basically be thought of as routing (previously called "proxying"
which was way too confusing). A call comes in to /1e8f937a8934/ and it matches
a sub-app path--we need to change the path from /1e8f937a8934/ to / for the
duration of the sub-app's handling of the request.
We used to do routing (nee proxying) at the httpuvCallback level, which added
a lot of complexity because it meant we were compositing HTTP handlers at both
the httpHandler level, and then again at the httpuvCallback level. This
refactor changes it so nobody speaks the language of httpuv except at the very
boundary of Shiny (webserver$createHttpuvApp), everything inside is either an
httpHandler or a wsHandler. So whether you're combining or routing or whatever,
everything now works the same way.
