github/shiny
1
1
Fork 0
mirror of https://github.com/rstudio/shiny.git synced 2026-04-29 03:00:45 -04:00
Code Issues Packages Projects Releases Wiki Activity

replace choicesNames with choiceNames, and choicesValues with choiceValues

Browse Source
This commit is contained in:
Barbara Borges Ribeiro
2017-03-22 00:33:50 +00:00
parent c6e1e40896
commit 2b28ea2da4
8 changed files with 78 additions and 80 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
man/checkboxGroupInput.Rd
View File

@@ -5,8 +5,7 @@
\title{Checkbox Group Input Control}
\usage{
checkboxGroupInput(inputId, label, choices = NULL, selected = NULL,
inline = FALSE, width = NULL, choicesNames = NULL,
choicesValues = NULL)
inline = FALSE, width = NULL, choiceNames = NULL, choiceValues = NULL)
}
\arguments{
\item{inputId}{The \code{input} slot that will be used to access the value.}
@@ -25,13 +24,13 @@ must not be provided, and vice-versa.}
\item{width}{The width of the input, e.g. \code{'400px'}, or \code{'100\%'};
see \code{\link{validateCssUnit}}.}
\item{choicesNames, choicesValues}{List of names and values, respectively,
\item{choiceNames, choiceValues}{List of names and values, respectively,
that are displayed to the user in the app and correspond to the each
choice (for this reason, \code{choicesNames} and \code{choicesValues}
choice (for this reason, \code{choiceNames} and \code{choiceValues}
must have the same length). If either of these arguments is
provided, then the other \emph{must} be provided and \code{choices}
\emph{must not} be provided. The advantage of using both of these over
a named list for \code{choices} is that \code{choicesNames} allows any
a named list for \code{choices} is that \code{choiceNames} allows any
type of UI object to be passed through (tag objects, icons, HTML code,
...), instead of just simple text. See Examples.}
}
@@ -65,10 +64,10 @@ shinyApp(ui, server)
ui <- fluidPage(
checkboxGroupInput("icons", "Choose icons:",
choicesNames =
choiceNames =
list(icon("calendar"), icon("bed"),
icon("cog"), icon("bug")),
choicesValues =
choiceValues =
list("calendar", "bed", "cog", "bug")
),
textOutput("txt")

13
man/radioButtons.Rd
View File

@@ -5,8 +5,7 @@
\title{Create radio buttons}
\usage{
radioButtons(inputId, label, choices = NULL, selected = NULL,
inline = FALSE, width = NULL, choicesNames = NULL,
choicesValues = NULL)
inline = FALSE, width = NULL, choiceNames = NULL, choiceValues = NULL)
}
\arguments{
\item{inputId}{The \code{input} slot that will be used to access the value.}
@@ -26,13 +25,13 @@ defaults to the first value)}
\item{width}{The width of the input, e.g. \code{'400px'}, or \code{'100\%'};
see \code{\link{validateCssUnit}}.}
\item{choicesNames, choicesValues}{List of names and values, respectively,
\item{choiceNames, choiceValues}{List of names and values, respectively,
that are displayed to the user in the app and correspond to the each
choice (for this reason, \code{choicesNames} and \code{choicesValues}
choice (for this reason, \code{choiceNames} and \code{choiceValues}
must have the same length). If either of these arguments is
provided, then the other \emph{must} be provided and \code{choices}
\emph{must not} be provided. The advantage of using both of these over
a named list for \code{choices} is that \code{choicesNames} allows any
a named list for \code{choices} is that \code{choiceNames} allows any
type of UI object to be passed through (tag objects, icons, HTML code,
...), instead of just simple text. See Examples.}
}
@@ -80,12 +79,12 @@ shinyApp(ui, server)
ui <- fluidPage(
radioButtons("rb", "Choose one:",
choicesNames = list(
choiceNames = list(
icon("calendar"),
HTML("<p style='color:red;'>Red Text</p>"),
"Normal text"
),
choicesValues = list(
choiceValues = list(
"icon", "html", "text"
)),
textOutput("txt")

16
man/updateCheckboxGroupInput.Rd
View File

@@ -5,8 +5,8 @@
\title{Change the value of a checkbox group input on the client}
\usage{
updateCheckboxGroupInput(session, inputId, label = NULL, choices = NULL,
selected = NULL, inline = FALSE, choicesNames = NULL,
choicesValues = NULL)
selected = NULL, inline = FALSE, choiceNames = NULL,
choiceValues = NULL)
}
\arguments{
\item{session}{The \code{session} object passed to function given to
@@ -25,23 +25,23 @@ must not be provided, and vice-versa.}
\item{inline}{If \code{TRUE}, render the choices inline (i.e. horizontally)}
\item{choicesNames}{List of names and values, respectively,
\item{choiceNames}{List of names and values, respectively,
that are displayed to the user in the app and correspond to the each
choice (for this reason, \code{choicesNames} and \code{choicesValues}
choice (for this reason, \code{choiceNames} and \code{choiceValues}
must have the same length). If either of these arguments is
provided, then the other \emph{must} be provided and \code{choices}
\emph{must not} be provided. The advantage of using both of these over
a named list for \code{choices} is that \code{choicesNames} allows any
a named list for \code{choices} is that \code{choiceNames} allows any
type of UI object to be passed through (tag objects, icons, HTML code,
...), instead of just simple text. See Examples.}
\item{choicesValues}{List of names and values, respectively,
\item{choiceValues}{List of names and values, respectively,
that are displayed to the user in the app and correspond to the each
choice (for this reason, \code{choicesNames} and \code{choicesValues}
choice (for this reason, \code{choiceNames} and \code{choiceValues}
must have the same length). If either of these arguments is
provided, then the other \emph{must} be provided and \code{choices}
\emph{must not} be provided. The advantage of using both of these over
a named list for \code{choices} is that \code{choicesNames} allows any
a named list for \code{choices} is that \code{choiceNames} allows any
type of UI object to be passed through (tag objects, icons, HTML code,
...), instead of just simple text. See Examples.}
}

16
man/updateRadioButtons.Rd
View File

@@ -5,8 +5,8 @@
\title{Change the value of a radio input on the client}
\usage{
updateRadioButtons(session, inputId, label = NULL, choices = NULL,
selected = NULL, inline = FALSE, choicesNames = NULL,
choicesValues = NULL)
selected = NULL, inline = FALSE, choiceNames = NULL,
choiceValues = NULL)
}
\arguments{
\item{session}{The \code{session} object passed to function given to
@@ -26,23 +26,23 @@ defaults to the first value)}
\item{inline}{If \code{TRUE}, render the choices inline (i.e. horizontally)}
\item{choicesNames}{List of names and values, respectively,
\item{choiceNames}{List of names and values, respectively,
that are displayed to the user in the app and correspond to the each
choice (for this reason, \code{choicesNames} and \code{choicesValues}
choice (for this reason, \code{choiceNames} and \code{choiceValues}
must have the same length). If either of these arguments is
provided, then the other \emph{must} be provided and \code{choices}
\emph{must not} be provided. The advantage of using both of these over
a named list for \code{choices} is that \code{choicesNames} allows any
a named list for \code{choices} is that \code{choiceNames} allows any
type of UI object to be passed through (tag objects, icons, HTML code,
...), instead of just simple text. See Examples.}
\item{choicesValues}{List of names and values, respectively,
\item{choiceValues}{List of names and values, respectively,
that are displayed to the user in the app and correspond to the each
choice (for this reason, \code{choicesNames} and \code{choicesValues}
choice (for this reason, \code{choiceNames} and \code{choiceValues}
must have the same length). If either of these arguments is
provided, then the other \emph{must} be provided and \code{choices}
\emph{must not} be provided. The advantage of using both of these over
a named list for \code{choices} is that \code{choicesNames} allows any
a named list for \code{choices} is that \code{choiceNames} allows any
type of UI object to be passed through (tag objects, icons, HTML code,
...), instead of just simple text. See Examples.}
}