TreeTable skip top parameter

[Myge91]

Hello,

I am working with the TreeTable with oData binding. As far as I can see there is no way to tell the TreeTable how many data it should load. I have tried it with urlParameters: {$skip:0,$top: 2000}, and length: 2000. Both parameters will be ignored from the TreeTable. I have seen that the top parameter which the TreeTable inserts itself is calculated by the number of visible rows + the standard oData 100 parameter. This is pretty annoying.

I want to load a bunch of data to prevent reload events when I scroll through the TreeTable. Is there a standard way to tell the TreeTable that it should load all data to prevent the reload/paging?

EDIT:

I have found the threshold parameter. Unfortunately even when I set this paramter to 20000 the TreeTable triggers a reload event when I scroll down. I can see in the batch request that the threshold parameter is used but not for every request.

[stephania87]

@Myge91 This is the default size limit for sap.ui.model - https://sapui5.hana.ondemand.com/sdk/#/api/sap.ui.model. Can you please check if you get the desired results with the model's setSizeLimit property (https://sapui5.hana.ondemand.com/sdk/#/api/sap.ui.model.Model/setSizeLimit )

In addition, you may be interested in the following GitHub discussion https://github.com/SAP/openui5/issues/927

[Myge91]

I have dived deeper into the UI5 coding and I found out that the one request in the batch is getting it's top parameter from a loop

https://sapui5.hana.ondemand.com/1.46.12/resources/sap/ui/model/odata/v2/ODataTreeBinding-dbg.js?eval

A little bit background on my usecase:

I want to load the first level of the treetable with an aggregationBinding. When the aggregation is executed I can see in the $batch that I have a count request and 2 requests which are loading the first level. I guess one is unnecessary. The last request which the aggregationBinding triggers looks like a bug to me because the request is similar to the second request except the top parameter:

[stephania87]

@Myge91 Please update this snippet to illustrate the settings and the problem - https://jsbin.com/nocobaxixi/edit?html,output

The example illustrates lazy loading of data into a TreeTable. The example uses OpenUI5 nightly build.

[imsuman]

Ok

On Oct 9, 2017 4:12 PM, "stephania87" notifications@github.com wrote:

@Myge91 https://github.com/myge91 Please update this snippet to illustrate the settings and the problem - https://jsbin.com/nocobaxixi/ edit?html,output

The example illustrates lazy loading of data into a TreeTable. The example uses OpenUI5 nightly build.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SAP/openui5/issues/1700#issuecomment-335122073, or mute the thread https://github.com/notifications/unsubscribe-auth/AdsCxLajNsPimhaK1Ob87CUBLcRBaTvlks5sqfibgaJpZM4PgXCq .

[Myge91]

I was not able to provide a running example on jsbin or plunker so I decided to give you a zip archive with mockdata. This example is runnable if you put it into a http server.

https://drive.google.com/open?id=0B2130ROZ3Xk9SEpnOEIxRjMtRmM

The example contains 1662 mockdata entries. I am loading 20000 data via the threshold parameter so all my data should be loaded at once. If I scroll down the treetable triggers a reload event which is useless and unnecessary because I already have loaded all my data.

Another annoying thing is when I scroll down it triggers a reload event to expand the leafs of the visible rows. When I scroll up to rows which I have already seen and loaded the TreeTable starts to load the data again.

[stephania87]

@Myge91 Check model.js in your example, and set oModel.seSizeLimit in the createDeviceModel function: createDeviceModel: function() { var oModel = new JSONModel(Device); oModel.setDefaultBindingMode("OneWay"); oModel.setSizeLimit(2000); return oModel; }

---

Example: https://fiddle.jshell.net/ff9pgvje/

[Myge91]

The parameter

oModel.setSizeLimit(2000);

does not make any changes when using tables. As far as I know for tables you should use the Threshold parameter:

https://sapui5.hana.ondemand.com/#/api/sap.ui.table.Table

The threshold defines how many additional (not yet visible records) shall be pre-fetched to enable smooth scrolling. The threshold is always added to the visibleRowCount. If the visibleRowCount is 10 and the threshold is 100, there will be 110 records fetched with the initial load. If the threshold is lower than the visibleRowCount, the visibleRowCount will be used as the threshold. If the value is 0 then the thresholding is disabled.

unfortunately when I add the parameter to the TreeTable

numberOfExpandedLevels: 1

it triggers the reload event when I scroll up or down.

The threshold parameter should enable smooth scrolling. This works when I use a table or when I don't set the above parameter. When I set the above parameter the smooth scrolling turns into an annoying scrolling.

Here are 2 videos which demonstrates the result when you use and not use the parameter

numberOfExpandedLevels: 1

This video demonstrates my struggle: https://youtu.be/U3mc8-CB4ZI

and here when I don't use the parameter

https://youtu.be/h0jGrLTJ8Hw

[Myge91]

@stephania87 Are here any updates?

[gerym]

Hi @Myge91 ,

I've created an internal incident 1870108516. The status of the issue will be updated here in GitHub.

Kind Regards, Gery

[RandomByte]

Hi @Myge91,

Sorry it took us so long to get back to you. I checked out the example app you provided.

I don't know how close this app is to your actual project and OData service but I see two issues here:

1. All the mock data for entity type MPResultTreeSet is on "HierarchyLevel": 0. However, with the binding parameter numberOfExpandedLevels: 1 you are forcing the binding to always try to load the child nodes of every single entity. I recommend setting this to 0 if you do not intent to automatically load a second hierarchy level.
2. All the mock data for entity type MPResultTreeSet defines "DrillState": "expanded". Note that for a single hierarchy data request, the data returned should be self-consistent. This means a node can only have an expanded drill state if its child nodes are part of this single response as well. In your example that is not the case. The child nodes are not even available in the service. Therefore all entities in your mock data should define "DrillState": "leaf". In production the drill state needs to be calculated dynamically by the OData service.

By setting the binding parameter numberOfExpandedLevels to0 and by changing the mock datas drill state to "leaf", smooth scrolling is possible. You can even omit the latter change, but that might still lead to other issues.

Why did you want to use numberOfExpandedLevels: 1 in your comment?

Best regards, Merlin SAPUI5 Core Development

[RandomByte]

I also made an unrelated observation I just wanted to make sure you are aware of.

In your Cockpit.controller.js you define oGanttChartWithTable: null as part of the Controller extension object. This will lead to the variable oGanttChartWithTable being defined on the prototype of the Z_OA_PM_S_COCKPIT.controller.Cockpit class. This means, if you create two instances of this controller class, they will access the same object with this.oGanttChartWithTable. Typically this is not intended. To have this variable on an per-instance level, I recommend to define it in the controllers onInit function instead:

onInit: function () {
    this.oGanttChartWithTable = null
}

[RandomByte]

Closing due to inactivity.