This Example demonstrates the next level of lazy load capabilities of the Flexicious DataGrid, that is each level of detail, as well as paging at each level in a lazy loaded configuration.

 

There are two properties to pay attention to here, both of which are defined at the column level:

 

 

 

 

 

Now let's examine the markup. At each level, we define filterPageSortMode="server" as well as itemLoadMode="server". What does this mean? Basically, what we're telling the grid is that, at each level, when the user navigates to a different page, or if they click on the sort, or if they filter, we need to go back to the server. For example, in this case, if an Organization were to have hundreds of deals, and each deal were to have hundreds or thousands of Invoices, loading the entire structure of that many records would not be practical. This is why we have filterPageSortMode=server. Please note, loading large amounts of data is possible, but not advisable. After a certain point, the amount of memory consumed by the objects themselves becomes high enough for the player to start causing issues. What this number is highly depends on what else is in the application, how big each object is, how many columns you have, what is your maximum nest depth and so on.

 

That said, let's look at the various event handlers: For each level, we have

flexdatagridcolumnlevelX_ itemLoadHandler and flexdatagridcolumnlevelX_filterPageSortChangeHandler

 

These are listeners to the events described in the earlier part of this article. Each handler basically calls out to the services layer, gets the data, and calls the setChildData method on the grid on result.

 

The item load handler receives a filterPageSortChangeEvent, which contains a parentObject property that represents the item being opened. We basically issue a server request for the children of that time, and in the result event, call the setChildData method passing in the parent item, the children, the level at which the parent item exists, and the total number of records that we have, if it is different than the length of the children collection (i.e.) if we are just pushing down a single page of data.  

 

One additional caveat: Since this grid is a server grid, the automatic calculations built into the Grid cannot evaluate the footer values. So for example, we have no way of calculating what the "total" of all Deals is - because, we do not have all the deals loaded. So, we have to provide this information separately. We keep track of this information in the _footerData property, and use a footerLabelFunction, the getFooterLabel, to populate the footer values.