height and width parameters

[KatRisk]

are these active in rpivotTableOutput? They don't seem to make a difference. Is there another way to control the size of the table?

[KatRisk]

just read through all the other comments, this doesn't work with box() in shinydashboard - that was my problem.

[smartinsightsfromdata]

@KatRisk Interestingly I'm having problems in sizing a shinydashboard box with another widget, rhandsontable.

The only way to work properly is to set box height and width. Set up scrolling is (almost) mandatory, as depending on the analysis you could have loads of columns to appear in a dynamic, unpredictable fashion.

See the example below (and my apologies for not understanding your issue sooner!):

library(shiny)
library(shinydashboard)
library(rpivotTable)
library(ggplot2)

data(diamonds)

header <- dashboardHeader(title = "Test")

sidebar <- dashboardSidebar()

body <- dashboardBody(
  box(title = "Pivot",width=8, height= 20, status = "primary", solidHeader = TRUE,
      tags$head(tags$style( type = 'text/css',  '#test{ overflow-x: scroll; }')),
  rpivotTableOutput("test")
))

shinyApp(
  ui = dashboardPage(
    header, sidebar, body),
  server = function(input, output) {

    output$test <- rpivotTable::renderRpivotTable({
      rpivotTable(data = diamonds)
    })

  }
)

[dholstius]

Is there a good way to enclose an rpivotTable widget in a DIV or other element that will resize with the widget? Otherwise, my first rpivotTable (in an .Rmd document) will generally overlap the next one, making it unreadable. :-/

Maybe there is, or could be, some sort of provision for a callback that will fire when the rpivotTable widget resizes?

[smartinsightsfromdata]

@holstius Frankly I do not see a solution for this.

As with any respectable pivot table, it is impossible to predict how many rows or columns an analysis will require. It is now very possible to have say >100 columns if your categorical variable it is so designed.

How would a similar resize would look like? Probably smaller than a stamp...

This is why in my modest opinion the best solution is to use scrolling wherever possible.

[dholstius]

If I look at the HTML, after it's done rendering, there's a "width" and "height" in the CSS attributes of the container. Something is calculating those once. Couldn't it calculate them again?

On Aug 31, 2015, at 9:56 AM, Enzo notifications@github.com wrote:

@holstius Frankly I do not see a solution for this.

As with any respectable pivot table, it is impossible to predict how many rows or columns an analysis will require. It is now very possible to have say >100 columns if your categorical variable it is so designed.

How would a similar resize would look like? Probably smaller than a stamp...

This is why in my modest opinion the best solution is to use scrolling wherever possible.

— Reply to this email directly or view it on GitHub.

[stvrd]

Hello and first of all, thank you for this great package.

I came across a similar issue using rpivotTable inside flexdashboard. After some failures I found out how to implement the same principle in flexdashboard. Here is my solution, thought might be helpful for someone. Just add this chunk at the beginning of your markdown:

'''{css, echo=FALSE}

.rpivotTable{ overflow-x: scroll; }

'''

[J-Sparks]

thank you so much!