Please see the following scenario:
There is the structure:
----- Sub-folder 1
----- Sub-folder 2
----- Sub-folder 1000
So, we have folder with thousand sub-folders.
Clicking on the Folder A in tree-view side of File-Explorer, we will have the following steps:
1. ResolveRootDirectoryAsTree - execute one time for Folder A in grid (acceptable)
2. ResolveRootDirectoryAsTree - execute one time for Folder A in the tree-view (acceptable)
3. ResolveRootDirectoryAsTree - execute one thousand times, for each sub-folder in the tree-view (very slow)
As you can see, the step 3 is the cause of very slow loading.
Is there any way to avoid this behavior? Do you have any suggestion?
Maybe to try to disable expand of nodes if there is a very large amount of data under them? Only to populate a grid, as the Windows explorer does?
When i turn-off expanding of the tree-view nodes (args.set_cancel(true) on node clicking for test purpose) i have very good response. Because, there are only two executions of ResolveRootDirectoryAsTree method.
Am i missing something here?
I red the article "Setup virtual scrolling in the RadGrid embedded in RadFileExplorer", but i still have the tree-view issue.
10 Answers, 1 is accepted
I am afraid that the desired loading cannot be achieved with the current implementation of FileExplorer. By design the control loads the first level children of each loaded folder in order to know whether it is empty or not (showing a plus sign before the folder icon).
The optimal solution I can suggest you is remove the TreeView from the visible controls of your FileExplrorer, enabling the Upper folder navigation, so the clients will be able to navigate through the folders of the control:
You are welcome, Petar - I hope the suggested approach was applicable for your scenario.
I've tried this approach (not showing the treeview), but the performance doesn't improve.
It past one or two years since the last reply to this post. Is ther any better solution for the performance problems of fileexplorer control?
I'm using the control with DNN and a custom content provider.
The problem as I see, is that when the control loads a folder with several items on it, the control perfromace is degradated notoriously.
I appreciate any help.
Are you able to replicate the same behavior outside the DNN environment with a similar content and configuration? If so, can you send us a runnable sample where we can reproduce and examine the problem further?
In case the performance issue occurs only in DNN, though, it will advise that you contact the DNN support about this problem, because they maintain the Telerik controls they provide and will be able to handle the problem internally.
Telerik by Progress
I'm using telerik 2015.2.804.40 version. Not the one provided by DNN.
I'm going to test the behavior outside DNN, but I don't think the behavior would change, because all the forum posts I read about this issues don't say anything about DNN.
As I saw on the Documentation and API references, the implementation of the FileExplorer doesn't change in the last version.
Is there any chances to change the base class for Custom File Provider, giving more control to the developer to implement paging and partial load on the treeview and gridview of the file explorer? Do you have it on your roadmap?
Unfortunately, we do not have any short term plans for improvements in the File Explorer and its File Browser Content Provider. The roadmap for R1 2017 is available here.
Please, submit your request in the AJAX Feedback portal and if it gains enough votes and popularity we will implement it for a future release.
Telerik by Progress
Mi name is Martin Lasarga, Product Manager of Axentria ECM. I work with Juan in the same company,
We are acctually thinking in changing the control because it is generating problems with some clients that have a big folder structure.
Can you please evaluate developing what we need and send us a quote if needed.
Please, submit a primary support ticket from your licensed account with your requirement and we will be glad to discuss further the details on our Feature escalation program.
Telerik by Progress