TreeTable: eliminate lazy loading permanently

Hi all,

I am using a TreeTable.

To be able to use the browser search functionality, I use the TreeTable.setPageLength() method to ‘eliminate’ lazy loading.
This works initially, however if the user sorts the treeTable the table behaves lazy again. Same after collapse/expand actions.

Is there a way to permanently eliminate the lazy loading behavior?

Any help appreciated,

Why do you want to disable it?

You can probably override TreeTable.isPartialRowUpdate() to return false to eliminate partial updates of TreeTable.

That is actually quite a good reason to not have lazy loading (to be able to do ctrl+f and type in some row detail to find the row in question). Surprising that no one has asked for this earlier.

Thanks for your reaction.

I notice that the problem I mentioned also applies to the Table class itself: SetPageLength works as long as the user does not sort the table.

I see that isPartialRowUpdate is also a method of Table, so I could subclass both Table and TreeTable to override isPartialRowUpdate.

I think however that a more ‘persistent’ pageLength settings might be more appropriate. If not, some warning to the temporary behavior of SetPageLength in the API documentation might be in place.


Came here after googling for a method to disable cahing on TreeTable.

Well, I actually have another reason for doing so:

If you have a FieldFactory set on it, with a bunch TextFields, let’s say one for each row, and you put a value in one of them, then start scrolling with the mouse wheel, without clicking out of the field itself neither pressing enter or so, if you go far enough (up or down) and let the “page counter” (that XX…XX number showing that cache its being refreshed) grow enough, the value you wrote will disappear when you go back.

So it seems this is a bug.

I haven’t tried it on v8 as I’m still on v7.

Nothing. Nada. Niente. No res.

I overrode TreeTable.isPartialRowUpdate() to return always false but that doesn’t seem to disable caching. I still see the counter showing partial updates from XX - XX (in batches of 12 elements?), and the behaviour stated in my previous message is still present.

Meh :confused: