For each group down we build one row to represent all the cells in the group across. The structure is very similar to tabular and summary, but the fact map has more complex keys and more of them. If you are interested in matrix report data, I would recommend doing a bug(rialize(ReportResult)) as I showed in my first article in the series to look more at the data. Then we do a nested loop, build a composite key, and get the numeric value at that location from the fact map. To get at the core numeric data at the intersections of the matrix, we have to build up lists of our groupings down and groupings across. The grouping levels even have hyperlinks, awesome! Matrix ReportsĪfter looking at a matrix report with one grouping in each dimension, I realized it could be shoehorned into the tabular data structure relatively easy, so I went with that approach. Here is what the summary salesforce desktop report looks like.Īnd here is the Lightning / jQuery Mobile version with groupings. To view the result, navigate to a summary report and check it out. Use the renderIf and set/else tags again to accomplish the conditional behavior: Next, change the main component to conditionally call the correct subcomponent depending on whether it is a tabular / matrix or summary report. This component is called once for each group in the summary report, and gives a grouping row that spans the whole table, and then iterates over the rest of the rows in the group. How do we use this data to render a summary report? With another component, of course! To get started, create a new component and name it reportGroupComponent.cmp, then enter the following: Creating a Lightning Component to Render a Summary Report Then we loop over the rows and cells in that group, in the same way we would do for a tabular report. You can see we loop over the groupings down, and use those grouping keys to get the fact map by a key we construct. Let’s look at how we build up the summary report in Apex: summaryReport contains some info about the group itself, then contains a similar, smaller two dimensional array as the tabular report, with just the data for that group. The summaryReportResponse type contains the same reportFields as the tabular report, but instead of a big two dimensional array of data, it has a list of summaryReportGroups. Since summary data is grouped, it needs to be stored in a different data structure. Of course this will only support one level of grouping for tabular and matrix, but that will buy us quite a bit of functionality on a mobile device. As you will see, all 3 report types can be represented with 2 data structures: tabular and summary. This wrapper will either have one or the other response type populated, with an additional “reportType” attibute which will let us know which report type it is, and which object we should be using. Since we may be returning different data types I put everything in one wrapper to rule them all: The code looks at the number of groupings down and groupings across to make a quick and dirty determination as to the report type and which method needs to be called to build the report and return it in the expected format. Here’s some simple code to figure this out: Depending on if it is tabular, summary, or matrix we will want to represent the data in a different user defined data type as well. In order to process the ReportResult properly, we need to find out what type of report it is. To this point, the Apex code provided isn’t designed to handle summary and matrix reports. You can reach him on Twitter or Thus far, this series on building Lightning Components has walked you through building Lightning Components that work with tabular reports. Guest Post: Daniel Peter is a Lead Applications Engineer at Kenandy, Inc.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |