height and width parameters about rpivottable HOT 7 CLOSED

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

from rpivottable.

@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)
    })

  }
)

from rpivottable.

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?

from rpivottable.

@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.

from rpivottable.

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 [email protected] 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.

from rpivottable.

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; }

'''

from rpivottable.

thank you so much!

from rpivottable.